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ABSTRACT 


Tne INTEL 432/670 microcomputer system contains tne iAPX 
452 microprocessor which executes compiled Ada programs. 
This thesis contains performance evaluation of the INTEL 
432/678 system in a multiprocessor/multiprocess environment. 
Benchmark programs from the Computer Family Architecture 
(CFA) study are encoded in tne Ada Programming Language and 
compiled on a host VAX 11/78@ before being downloaded to 
INTSL MDS 2800 for furtner transfer to the INTEL 432/672 
System for execution. The historical development of computer 
arcnitectures as well as a systematic description of tne 


INTEL 432/672 syStem are included. 
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I. INTRODUCTION 


A. BACKGROUND 

An Integrated Crrcuieu rc) is a Small Silicon 
semiconductor crystal containing electrical components such 
as transistors, diodes, resistors, Capacitors, oT 
interconnected digital gates. AS the technology of IC’s nas 
Porovea, the number of components that can be put on a 
Single silicon chip nas increased. If a package contains 
several logic eates it is considered to be a small-scale 
integeration (SSI) device. Medium-scale integeration (MSI) 
fewrces Contain 1¢ to 190 gates and perform a complete logic 
function. Large-Scale integration (LSI) devices pertorm 
logic functions with over 1¢¢ devices and veryrlarg2=-scale 
integration (VLSI) units contain thousands of gates in a 
Single chip. The INTEL iAPX 432 contains 15¢€,0@U transistors 


On two chips and is considered a VLSI device. 


Bee eso lo DESCRIPTION 

The Intel 432/678 system is a commercial product that 
uses the iAPX 432 microprocessor. Incorporating many new 
architectural features, with the goal to significantly 
reduce the sottware cost, tne Intel 432 nas been neraldea as 
“the most significant architectural development in tne last 
5-10 years [Ref. 1]. In addition to tne VLSI tecnnoloey, 


the 452 contains architectural advances tfmat enadle 


2 





Proleme mia, lon of transparent multiprocessing eng 


Qu 


protected computing and communications environment. 
The purpose of this thesis iS to continue a series or 
benchmark performance tests on the Intel 432 that nave been 


reported in Shoop [Ref. 2] and Applegate [Ref 3]. Tne goal 


of these tests is to determine it the 432/67€ system is 
capable of sustaining incremental performance improvements 


as processors are added to the system. 


C. THESIS ORGANIZATON 
This thesis iS composed or three major sections. Cnapter 
II presents a brief history of computer architecture 


development from the first electronic computers to tne 


Opeect sOnrented architectures. Chapter III provides a 
systematic description of tne Intel 432/670 system while 


Chapter IV provides the actual 2encnmark performance 
evaluations of the Intel 432/678 system in tne 


multiprocessor/multiprocess environment. 
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IT. HISTORICAL DEVELOPMENT 


Since computer systems architecture is not restricted to 
the sole aSpect of nardware, it iS not easily defined. 
Functional boxes and their complexity, tne interconnection 
between tne boxes, switcnes, controllers, tne way messages 
are passed and received, and tne blend of hardware and 
software Mealuresmemust be. considered. in tne ene Tae 
architectural structure. The [ntel 452 architecture is the 
result of an evolutionary development in computer systems. 
It incorporates many advanced features whicn nave evolved 
throughout tne history of computers. “accordingly, to 
maids me sprOper perspective of the concépts of tne 
Intel 452 a brief history of computer architecture 
weve lOpMenbe.s presented. 

One of the earlier electronic computers was completed in 
1946 at tne University of Pennsylvania Moore Scnool of 
Engineering. ENIAC, capadle or performing nearly o3¢¢¢ 
Sccuplonemer sumptractions per second, consisted of more than 
1E2@¢@G vacuum tubes and 1500 relays and was used tO compute 
Daliictercmmurea /ectories. Wired for specific computeaticns, any 
modifications or program replacements on BNIAC required new 
wiring and its associated excessive set up time. [In an 
effort to elininate the setup time, von Neumann ard otners, 


Gonsurtine at the Moore School of Engineering, désigned tae 








Pirst stored program computer. However, the fies: ¢ 
Operational stored program computer (EDSAC) was built at 
Cambridge, England in 1949. In addition to being tne first 
computer to execute stored programs, EDSAC irtroduced tne 
notion of memory hierarchy through the primary memory and 
backing drum. 

Meanwhile, von Neumann continued nis researcn at the 
Institute for Advanced Studies (IAS) at Princeton wnere ne 
developed the von Neumann architecture which is in wide use 
today. Tne von Neumann architecture is considered to be 
based On fOur “wey concepts: 

ieee A Single, sequentially adaressed memory. A 

program apm tts = =adata “are stored in a single 


memory, and the memory is reterenced with 
sequential addresses. 


Ce A linear memory. Tne memory is one 
dimensional, or nas the app@drance of VECTORS 
of words. 


3. No explicit distinctions between 1OStruc tions 
and data. PAS t ruc hens and data are 
distinquisned yen. oefostae ibis by tne operations 
directed toward tnem. 

co meaning 1s not an inherent part Of, Catae 
[Rer. 4] 

Liemetmiye DrOgremming StLyYleS Sunoported single user, 2on= 

subroutine environments that employed a looping tecnnique by 
MmOai1t ying Pst ruc GLOnS « Slice lt nSECUucCtLLOn  modist beation 


generated only serially reuseable code, multiprogrammine was 


not feasible and index registers were developed at the 


1S) 





University ot Manchester to make it possible to call 
emoroutines, pass palrpameters, dnd generate reentrant code. 
UNIVAC I, built tor tne Bureau of Census, had a tave 
system that used error cnecking procedures and obuffering 
capabilities to read tapes botn forward and backward. It was 
movendedad fOr both scientific and commercial applications and 
Saieemvce considered the first successful commercial computer. 
mee system architecture durime this perfod 1S cnaracterized 


moe rienre <2.l. 
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Murine re.) sa rly SyYStem Archi tecture 


AS eomputer dadpolications advanced into commerciel 


Preles , Gye) intensive requirements were generated. 
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Arcnitecture improvements to ennance computational Specde 
aad enable overlap to permit interleaved 1/0 amd 
computational operations were developed. Pipelining, a 
technique used to speed computer operations by multiplexing 
memory accesses .pa with instruction decoding and execution, 
memcne example of enhancement. 

Systems became faster, Smaller, and more reliable 
throughout the 1960°s as transiStors and integrated circuits 
allowed the pbuilding of more general purpose registers and 
aopurdrearnenitectures., Figures 2.2, 2.5, and 2.4 depict me 


architectures of this period. 
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Moeunre 2.2 Utial Port Memory Architecture 
PiLecure Boe. representing a dual port memory 


arcnitecture, provides a faster access patn but demands 


extra nmardware in the memory which performs independent [1/0 


eG 





operations. The I/O bus structure, Figure 2.3, connects tne 
im On devices to memory throwgn device controllers tnat are, 
in many cases, mini-computers. It still requires a resource 
maneeer or a distributed Gemtrol discipline. Tne central 
System controller shown in Figure 2.4 is bdaSed around a 
giant switch which controls multiple processors and memory 


units ina modular fashion. 


| | 
| | 
CPU ! 
coe ena 
| 
i 
| 7 | 
| MEMORY | 
monoonnnannnn= 
| 
aio iy A ee AS aia in ee eS CO A ele ER 
| 
| | ! 
| | j 
| DEVICE ! DEVICE DEVICE ! 
' CONTROLLER ! CONTROL ESR «| ! CONTROLLER | 


Figure 2.3 I/0 Bus Arcnitecture 


As hardware cost decreased, designers eliminated the 
complicated central I/0 control in favor ot a bus oriented 
Seructune meerigure 2.5). It is tlexible, modular, and 
Conceprualia simple and most architectures today contain 
Momeaceonsceof this bdDus@eriented structure. S-10¢, MULTIS8US, 
EXORBUS, and VMEbus are a few bus oriented arcnitectures oa 


moe Current Market. 


ie 
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Figure 2.4 Central System Controller 


As fast processors were developed, etforts to Keep tne 
processors busy, while tne slow peripnerals were reacting to 
instructions, culminated in multiprogramming and the 
associated task switcning and nardware Memory protection 
instruction set ennancementsS. Microprogrammineg, a tecnnique 
wnich opreaks eacn instruction into a series of elementary 
Steps was also developed in the 1962°s to reduce tne cost of 
the sopnisticated instruction sets by making it easier to 
develop a compatible series of computers that covered a wice 
range of performance. 

Paging and segmentation were developed to support tne 
concept of virtual memory. Additionally cacne memory, whicn 
is fast memory pnysically close to tne central processor, 
was developed to improve CPU performance. In general, the 
advances in menory management resulted in a five tevel 


hierarchy that consisted of registers, cache, main memory, 


SUS, 








and nhign-speed disk or drum for backing store and low-speed 


disk or tape for long-term program storage. 
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Figure 2.5 pingle Bus Arcniwecure 


Multiprocessors, another concept introduceaqa in the 
1962°s, are cnaracterized arcnitecturally by wnetner tne 
processors are identical, exscute the same iastruction 
stream, or operate on one or more data streams. However, it 
was the Intel 4004 microprocessor which was developed in 
1971 tnat was responsible for a continued unpresidented 
evolution in technology durine the 197@°s which produced tne 
inexpensive processors and encouraged the use Of 
multiprocesssing. Specialazed darabase processors and 
arithmetic processors are a few examples of expansion in 
Ped Sead C Qu. 

AS complexity in microcomputer systems increased with 
decreasing nardware cost, software systems were expanding to 


take advantage ot the new capadlities. Software engineers 


2D 





soon discovered tnat large software systems were among tne 
most ditficult engineering projects. The use otf Subroutines, 
block structured languages, procedures, functions, stepwise 
refinement and Structured programming were tecnniques 
developed to assist in solving the software engineering 
problems. Data abstraction, employing the concepts of 
encapsulation of data structures, uniform procedure/message 
MebereacS, and decomposition of design, was a furtner 
extension of the effort to produce reliable software. 
wo Le rnese SoOtuweares CONGeDtS mwere being geve toned: 
Ewoliurnonetn hardware protection structures can be observed 
in ‘supervisor vs. user state in the IBM 368 systems, 
Oerearchical rings in Muitics, and multiple domains in tne 
Plessy s/250, CAL/TSS, Hydra, and CAP. Key concepts of tnese 
domain pased systems include independent address spaces, 
Ccapability~based addressing and access control, and the 
Jecomeesrtion Of the operating system into a useful set of 
abstractions. {Ret. 5] Additionally descriptors and access 
Comunomemmcanceptsewere introduced to provide protection py 
establisninge a reauirement for authorization to access cata 
elements. 

A major departure from one of the key concepts of the 
von Neumann architecture is ooserved in tagged storage. All 
information witnin storage is self-identifying. Based on tne 
information contamnedesin the tae field, the machine 


instructions can determine tne s@mantics of eacn operation 





as well as the data conversion rules to employ. With tne 
tag field vou nave a strongly typed environment” tnat 
pronidbits operation on improper data types and permits. the 
deferment of binding instructions to data attributes until 
the time of execution. 

As we examined tne nistory of computer development, we 
Saw that the early machines used Simple hardware operations 
such as move byte and “add integer” which manipulated 
hardward-recognized data types such aS bytes and integers. 
AS technology progressed and computer hardware egained 
Pumcuronaiity, ‘ore complicated operations sucn as floating 
point were moved into hardware, which substantially 
increases tne speed of tnese operations. Ennancement of 
Standard programming methods as well as Puaranteed 
ewer ce env Of Gata protection were additional benefits 
derived trom novineg Software tunctions into hardware. 

Recognizing that continued advancements in arcnitectural 
enhancement would result in more data Structures teing moved 
into hardware, designers developed a methodology for viewing 
these abstractions that would contribute to tne concept of 
raising the level of nardware/software interface. One such 
metnodology tnat integrates data abstraction, domain based 
BEOtectwem, ana Nieh level system functionality is the 
object oriented metnodology. 

PMiem=eGoncept Of uSine objects can be observed, as” long 


ago as 1960, in LISP, where atoms have properties that can 


ae 








be related to real world objects. SIMULA, an extension of 
ALGOL intended for simulation, included the idéa oft 
internally represented objects as instances of classes. In 
an effort to produce a programming vehicle that would reduce 
tne man-macnine semantic gap, Alan Kay, wnile stiil a 
graduate Student at the University ofr Utah, investigated 
Simulation and graphics oriented programming languages. 
Paxine Many of his ideas, sucn as classes and objects, from 
SIMULA, Kay helped design the language FLEX. Continued 
refinement of FLEX carried tne object oriented paradigm to a 
sSmootner model by incorporating ideas from LOGO, a language 
Gesvened Lor teaecn programming concepts to children, and 
resulted in the Smalltalk programming system. 

Mion cem is an atStraction that is usually considered 


to nave the following characteristics: 


P—Ooec tc are temporal, they exist in time; 


2. objects are mutable (Subject to change), and Mave a 
state; 


S.- obdjects can be created and destroyed; 
4. objects are particular (distinct), and can 0.be 
shared. (Rer. 6] 
im fseneras objects are similar to packages in that an object 
is a data Structure that contains information in an 
organizei manner, including a set of basic operations trat 
Tee “cttevwemanipulate tne data structure. It can be referenced 


as one entity and has a label that tells its type. 





AS Kay continued his concept development tnrouenout the 
Hore S$, tne idea of using an Onyect oriented metnodo logy aio 
model complex real world issues began to emerge. IEM uses 
object oriented design concepts for complex projects. Grady 
Booch, formally of tne USAF Academy, advocates an object 
oriented design using Ada to enforce a clear desien 
structure. Just as Smalltalk nad used objects to represent a 
meeered level of abstraction, object~based arcnitecture was 
selected to model the erowing hardware complexities. 

Based on an integrated approach to data abstraction and 
domain-based peovection, object oriented architecture 
includes a form of capability based addressing and supports 
hign level system functions such aS memory management, 
process management, and processor management. Fecause the 
arcnitecture is rooted in data abstraction, good software 
design methodology is encouraged which will result in 
software systems tnat will be more reliable and nave reduced 
software life cycle cost. Elements of oodoject-oriented 


moecti tecture include: 


1. Objects for system management and control. 


2. Objects for program environments, flow of control, 
and intercommunication. 


3. Facilities for user object extensions and system 
object type management. 


4. Object addressing and protection mechanisms. 


5. An instruction interface. [Rer. 7] 
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System management obdjects include processor Go jeCc Us, 
process objectS and resource objects. While a protessor 
object is a memory based data structure, process opjects 
represent a unit of computational work for tne processor and 
contain information regarding scheduling and dispatching. 
Various resource objects are queue-lixe structures used to 
bind physical processors with ready-to-run processes. Ey 
HMepresenting ali resources as objects, a uniform interface 
for all syStem functions iS obtained. 

Environment and control objects include data objects, 
Birmucwron ODJECtS, domain objects, context objects and 
control link objects, while communication objects consist of 
mescsaee dnd port objects. Port objects are asyncfronous 
communication pathways between processes and provide tor the 
queueing of waiting nessages aS well as resolution of speed 
disparity between concurrent activities in the system. An 
OenecGesoniented architecture with a bullt in software 
metnodology should include support for representing typing, 
type manager packaging, and= ebject aWtnentication ane 
creation. Object addressing and protection mechanisms are 
required to support references, mapping and protection. 
Mimidluywe tne object oriented instruction interface provides 
a uniform interface witn uniform referencing to all tne 
object based facilities. 

A syStem environment can be viewed as a single set of 


objects which are addressaple by everyone. Ranging from tne 





primitive storage segment naving all tne cnaracteristics of 
a von Neumann store, to an abstract entity wnose physical 
form is hidden by tne arcnitecture and wnose meaning is 
defined solely by the transformations that can be performed 
on 1G; objects provide Still more DRoLecrtl on bY 
encapsulating data and program modules in a structure wita 
not only well defined external visibility but carefully 
nidden internal Structure. 

In summary, obdject oriented arcnitectures were adapted 
to model the wide variety of hardware and software 
constructs that have been developed to ennance computer 
Systems efficiency and reliability. In addition to raising 
Piewevel at which the transition from hardware to software 
occurs, SUNe Ct sorrented Sarcnhitecture enjoys tecnnoloey 
independent design through its information hiding structures 
and supports a variety of language structures including 
operating Systems ani reliable low life eycis cost 
applications software. For tnese reasons, [Intel Corporation 
has chosen the objectroriented architecture as the 


predominant construct of the iAPX 452. 
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IIT. INTEL 432/678 SYSTEM DESCRIPTION 


peeleS chapter will present the characteristics and 
advantages of tne LAPX4352 over the conventional 
microcomputers. Additionally, the Sonecepts Of “OD JECT 
oriented architecture will be presented in a simplified 


form. 


A. THE 432 OBJECT ORIENTED ARCHITECTURE 

In an effort to find a Solution to the software crisis 
while providing transparent multiprocessing, tne Intel 432 
designers” principal desire was to provide direct execution 
comer support for both data abstraction and domain-based 
Operating systems. Recognizing that both of the objectives 
could be supported by the object model, Intel selected the 
Ome t Oreegted architecture .as tne principal design 
Gomstruct to support a software methodology. Paks 
architecture provides mechanisms to help tne programmer 
follow the object oriented methodology. 

1. Object Oriented Methodology 

Wnat does object oriented metnodology mean? One 07 

the best wayS to modularize programs is by using tne 
Eemmcdple of information nidinege as defined by D. L. Parnas. 


fhe baSic idea is that a module should contain a collection 


of related procedures and associated data structures on 
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whicn they operate. Procedures outside tne module snould not 
have access to the implementation details inside the module. 
The data can be referenced from outside tne module only by a 
call to one of the procedures inside the module. 

Modules that result wnen tnis principle is applied are 
referred to as abstract data types, extended types, or 
Parnas modules. Intel refers to tnem as type managers. 

At the same time that programming languages research was 
focusing On the concept of a type manager as the solution 
to the modularization problem, operating system researcn was 
defining a very similar structure, the protection domain, 
as the solution to the security problem. Since operating 
System personnel were concerned more with security than 
modularization, they concentrated on the data in these 
domains, rather than tne procedures which were the focus of 
the language research. Assigning the name ‘objects to the 
data items associated witn domains, operating systems 
personnel called the whole information hiding methodology 
Oonlecymme tner the oriented meétnodology or tne object model. 

Although experimental studies have demonstrated that 
Objects are superb models for modern software systems, the 
overnead required to maintain the model is too excessive to 
permit efficient inplenentation without direct hardware 
support. [Ref. 8.] The Intel 432 has hardware mechanisms 


that permit recognition of the following objects: 
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Processor 

Processes 

Dispatching ports 
Interprocess messages 
Domains 

Context 

mst ruction 

Data 


(DNXNOD OP AMF 


to permit an effective management of tne systems 
configuration and its individual resources as well as 


SupeOrt Tor data abstraction. 


B. INTEL 432/679 SYSTEM 

Urea zing tme ecdvanced architecture of tne WAR 4352 
Micromainframe VLSI computer, the 432 family presents a new 
architecture in tne world of microcomputers which contains 


the tollowing salient characteristics. 


1. Part of the operating system iS contained in silicon 
and it is called Tne Silicon OS. [t supports 
process scheduling, interprocess communication and 
dynamic storage allocation. 


Zee ee system operates in botn single processor and 
multiprocessor contigurations and it can include upd 


to eignt (8) processors, altnougn tne 432/678 system 
Can only support five (5) processors as limited by 
pene  nunber of slots available in the motner board. 
If one processor fails, the rest of the 
SyStem can usually continue to operate. 


3. Hardware recognition of eignt (8) data types. 


4. Hardware control functions for 16 ana 82 bast 
multiply, divide, and remainder operations. 


5. Hardwired control functions for S2, 64, and &@ 
bit floating point arithmetic. 


Srpemarawired Grror correction and code protection. 


7. Object oriented desien. 
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S. Botn abstract data types and objects are supported 
Dy hardware recognized, hardware protected and 
hardware manipulated Structures. 

9. It has an @xtremely large virtual address Space 
(2**4G bytes) and hardware supplied mechanisms for 


implenenting virtual memory systems tnat can 
exploit this address space. 


The 432/672 system consists of tne tnree (3) subsystems: 


1. Memory subsystem. \ Central Syster 
2. Processor subsystem. / 
5. Peripheral subsystem. 


and two busses: 


1. System bus backplane. 
2. Multibus backplane. 
Before analyzing each one tne subdsystems, tne following 


observations of tne systems architecture are germane: 


1. Tne whole memory is accessible by all GDPs. 


2. The system iS tneoretically expandable to include 
anv number of processors (GDPs). 


So. 8S bit or 16 bit based sysStemS can be connected 
to tne system for performing I/O. 

Figure 3.1 TlluStrates the boundary between the central 
system and peripneral subsystems. In addition to seperating 
data processing from input/output processing, this doundary 
Serves aS a protection barrier. Alle anformation in’ central 
system memory is snielded oy 4352 nardware against 
unauthorized accesses but the peripneral subsystem may oor 


HavenoOteprovide protection. 


50 





1 { 
| | 
1 1 
epee | 
Central System eee Hee -_—_  —= ! 
! (Data Processing) yo ae | 
ere m rnwnnn nnn / 
Interconnect Bus eke ae 
: w----------- | --------------- \ : 
| 1 1 | 
j j ! ! 
meee eet eee ee fe eee 
a oratert aCe we TOCeSSOcee sess cee eee, 
Se een Pesci Ne POEs Fda se | 
: eet | 
1 ! | | 
emma err nt een ee 
| (1/0 Processing) | Peripheral ! 1 
Subsystem | 
1 1 


Figure 3.1 General 432/672 System Oreanization. 


Maewire o.c Lilustrates a nyvotnetical configuration that 
employs two veripheral subsystems. The main system's 
hariware is comvosed of two GDPs and a common memory that is 
Snared by tnese processors. Tne main system’s software is a 


collection of one or more processes that execute on the 
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Figure 3.2 Main System and Peripneral Subsystem. 
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When the salient characteristics of the 432 are viewed 
with Respece. to tite levels of adaPrecnmrecture within a 
computing system cited by Meyers [Ret. 9], it becomes clear 
that functions have been moved from botn hign level 
language and operating syStem to the hardware which raise 
the boundary line between hardware and software closer to 
the end user. Figure 3.23 illustrates the nardware-software 


interface. 


nign level 
language 


LAPKX 423 mainframe 


minicomputer 


microcomputer 


uv 
at 
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Figure 3.5 Hardware - Software Interface 


Appendix A gives a comparison of tne 1APX 432 
arcnitecture and tne arcnitecture of tne conventional 


mainframes. 


Tne central system consists of tne memory and tne 
processor subsystems. 
a. Memory Subsystem 
The memory subsystem resides on tne system dus 


backplane and consists of: 
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1. One memory controller (MC) board. 
2. One to Ten Storage Array (SA) poards. 
So. A Memory Interleave (option). 


(1) Memory Controller Board. The memory 
addressed by the 432 is organized in elgnt-bit bytes. In 
Spite of this Intel Says that the 432 is a 32 obit 
microprocessor and that it can perform 32, 64, and 80 bit 
floating point aritnmetic because with any read request from 
the system processor(s), an additional signal determines how 
many bytes snmould be addressed. THs Vsn voal ted byte 
addressability. Thus, based on the processor(s) requests a 
word can consist of 1, 2, 4, 8, or 10 bytes and consequently 
8, 16, 32, 48, 64, or 88 bits can be addressed. 

(2) Storage Array Board. Eacn Storage Array 
(SA) board contains 256K & bit bytes of memory. A memory 
controller can control up to 16 SA’S or 4.896 Megabytes of 
memory. However, in tne current 432/678 systems.tnere are 
only 1@ slots available for SA Ddoards. 

Althougn the 432 is a S2 bit microprocessor 

tne words are organized in 39 bit wide banks. The seven (7) 
additional bits contain Error Correction Code (ECD) tor each 
So aeoitewordamernis 1s controlled by togic eristing on every 
SA board for generating, checking and storing this ECD. 
Finally, tne SA boards are organized in 64K byte banks of 32 
bit words, four bytes per word. 

(3) Interleave Option. Tnis option can be 


selected by setting tne jumpers of tne MC board to tne 
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proper position. Tne interleave option is available to 
enhance system performance. The interleave concept uses two 
banks of memory with alternating addresses to provide faster 
data accesS by overlapping memory operations. If tne 
interleave option has been selected, SA boards must. be 
installed in pairs to provide tne alternate banks. 
Db. Processor Subsystem 
The processor subdsytem, which resides on the 
system bus backplane and consists of tne GDP and IP boards, 
is discussed under component arcnitecture. 
ec. Peripheral Subsystem 
The peripneral subsystems are discussed in the 


Basic I/O Model and Windows Sections. 


C. COMPONENENT ARCHITECTURE 
In this section, the basic architecture, of the major 
components of tne system ( GDP and IP) are presented. 
1. Architecture 
The 432 GDP consists of two chips the instruction 
decoder/microinstruction sequencer-432G1 and the execution 
firteeweoc., “Anpendix B contains the pin description of each 
Chip wnile Figures 3.4, and 3.5 show the block diagrams of 
the 43201 and 432@2 chips respectively. 
In general, the GDP is organized internally as a 
three-stage microprogram-controlled pipeline. The first 


Stage is the instruction decoder (ID), the microinstruction 
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Sequencer (MS) is contained in tne second stage while the 
third stage nouses the execution unit. 

The first two stages of the pipeline are physically 
located on tne 43201 chip (Figure 3.4), wnile tne tnird 
Stage is the only function of tne 432062 chip (Figure 3.5). 
Actually each stage of tne pipeline is an independent 
subprocessor, which operates until tne pipeline is full and 
then halts and waits for additional work. 

a. Instruction Decoder 
Tne first subprocessor of tne pipeline is 
the Instuction Decoder (ID), which pertorms the followine 
functions: 
1. Receives macroinstructions. 
2. Processes variable lenetn ields. 
Oo. kxtracts logical addresses. 
4. Generates starting addresses for micro- 
instruction procedures 
oe cenerates microcinstructions for simple 
operations. 
The general task facing tne Instruction 
Decoder is to interpret the macro-instruction stream, to 
determine whicn micro-instruction sequence should de 
initiated next and to extract logical address data. 
Additionally, the Instruction Decoder provides a mechanism 
to recover from an instruction that faults. The information 


necessary for fault recovery iS retained by the Instruction 


Decoder until the instruction is successfully completed. 
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Figure 3.4 432401 Block Diagram. 


db. Microinstruction Sequencer 
mae. second suborocessor in = tne pipeline  1< 
the Microinstruction Sequencer (MS). The role of the 
fecroinstruction Sequencer is to decide wnoich 
microinstruction Should be Sent to the Execution Unit for 


Gece cycle. 
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c. Execution Unit 
The 43202 contains the Execution Unit (EU) 
which is third stage of tne GDP pipeline. Tnis unit receives 
microinstructions from the 43201 and routes them to one of 
tn2@ two independent subdprocessors that make up the SU, the 
Data Manipulation Unit (DMU) or tne Reference Generation 


Unit (RGO). 
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Figure 3.5 43292 Block Diagram. 


Tne Data Manipulation Unit contains the 


registers and arithmetic capabilities necessary to perform 
hardware recognition of eignt (3 ) data 


Wemes, 16, and 32 bit multiply, divide, and remainaer 
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operations. Additionally it contains tne control functions 
for 52, 64, and &@ dit floating point arithmetic. | 

The Reference Generation Unit provides the 
translation of a 49 bit virtual address into a 24 bit 
physical address, a hardware enforced domain protection 
system (read, write, alter, accessed), nandling sequencing 
for &, 16, 32, 64, and 8@ bit memory accesses, and 
controling the on-cnip top-of-stack register. In general, 
tne Execution Unit manipulates data and translates tne 
logical addresses into physical addresses. 

d. Processor Packet Bus Definition 

Tne Processor Packet Bus contains 19 signal 
Bes . Sixteen (16) Signal lines are the three-state 
Aiddress-Control-Data lines (ACD15 througn ACD®@) and tne 
remaining three are control lines used to request the bus, 
enable the buffers for output from and an interconnect 
Status line. In general by sending tne proper signals, tne 
System bus is used as an address, control or data bus. The 
mecnanism for tnis multi-use of tne system bus is quite 
complex and it is explained in Intel’s manuals. 

2. Interface Processor 
The Interface Processor (IP) interfaces tne GDP’s 

and the employed peripheral subsystems by providine I[/0 
[cli t1esS., An IP maéps a portion of the peripneral address 
Spac® into tne iAPX 432 systen memory via four (4) 


different IP windows that may be mapped onto four (4) 
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diftterent objects located in main memory, with the same 
protection mecnanisms as any iAPX 432 processor. Figure 3.6 
illustrates the internal architecture ot the Interrace 


Processor. 
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Fieure 3.6 Interface Proressor Block Diagram. 


D. DATA MANIPULATION 
1. Hardware Recognized Data Types 
Computers store data in their memory in terms of 
zeros and ones. What these strings of bits represent depends 
upon the interpretation given to them by tne computer. This 


neans that two or more different pieces of information mignt 


09 





be represented by exactly the same strine of ditS and “so 
this string could be interperated as an instruction, 
integer, or character. These baSic representations are 
called nardware recognized data types and nave tne tollowing 
characteristics: 

1. Each instance of a type is an addressable unit 

of memory. 

2. Each type has associated witny tt. a set “of 

Operations that can be performed on this type. 

Tne combination of all tne hardware recognized data 
types with all the operators which act upon them constitute 
Pee anstruction set of the computer. These hardware 
recognized data types are called primitive data types 
because they are used to construct more complex data 
Eeructures. 

Tne Intel 452 recognizes eight different primitive 
mova types, Which are divided into four classes: Cnaracters, 
Ordinal (unsigned integers 16 and 32 bits long), Integer and 
Heat. “ienre 3.7 provides tne formats of each of tne eight 
hardware recognized data types [Rer. 15]. 

2. Structured Data Types 

The term structured data types is used for ordered 
aggregates of primitives. The two structured data types that 
can be accessed by the 432 are Arrays and Records. Although 
not supported by hardware, the 452 provides a mecnanism that 


allows Structured data types to be manipulated easily. 
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Figure 3.7 Primitive Data Types. 
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Gee sbostructions 
Lae instruction Set of the 432 is rich and Supports 
five out of tne six operations wnich, according to Mvers 
(Ref. 18], a language directed architecure must Porte. It 
supports string processing, arithmetic operations, program 
flow, error nandling, and program tracing, while it is 
Meooime the editing operation. In addition, it supports 
segment and object creation. A summary of tne 432 
instruction set is contained in Myers [Ref. 11]. 
4. Instruction Format 
The instruction format of the 432 has four fields. 
Tne first field (class) specifies now many operands are in 
the instruction. The second (format) specities new tne 
operands are to be accessed. The third (reference) specifies 
tne logical addresses of up to three operands. Finally, tne 
fourtn field (operator code) specifies tne operator. The 
segment selector identiries tne segment that conteins the 
operand, while the displacement locates tne operand witain 
the segment. Figure 35.8 illustrates tne instuction format. 
J. Addressing Moaes 
The base and index values are used to locate the 
operand within the segment eitner by containing tne vaiue 
itselt (direct addressing) or by pointine to a location 


een win turn points to the location where tne value of the 


operand nas been stored (indirect addressing). 
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Figure 3.8 iAPX 432 Instruction Format (tnree operands) 


A number of combinations (dase direct/indirect and 
index pibeectyindi: rect) of direct and indirect reterence are 
called addressing modes. The system selects tne most 
efficient wavy for adaressing tne various data types as 


Pollows: 


1. Base and Ind®x Direct : used to access scalars. 


2. Base Indirect, Index DYrec t > used to access 
records. 


3. 86©0Fase Direct, Index Indirect : used tO @ecess 
Soavic arrays. 


4. Base and Inaex Indirect : used to access aynamic 
arrays. 


Figures 3.9A and 3.98 illustrate tne four add ressi 22 mades:. 
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Scalar: Index and Base Specified Directly 
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A special data Segment maintained by the nardware 
for expression evaluation is called tne operand stack. 
Accesses to the top of the operand stack are called implicit 
references and the items are added to or removed from tne 
tack On a last-in first-out (LIFO) policy. The current 


stack top is pointed to by a hardware maintained stack 


pointer. 
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Static Array: Index Specified Indirectly 
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Figure 3.9B Addressing Modes 
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An effort has been to speed up execution throuen 
instruction decoding. A large percentage of a computer’s 
time is spent fetching instructions; hence the faster tne 
instuctions can be fetcned the less time will be spent 
waiting to execute an instruction. 

The 432 uses bdit-variable instructions versus. tne 
fixei~-size length wnich is used by most machines. Tnis 
flexibility implies tnat there is no constraint for the 
instructions to Start or to end on byte or word boundaries. 
The size of the instructions varies from 6—bit lone for the 
shortest up to 544 bits lone ror the longest instruction. 
ANotner difference, in the instruction encoding, is that in 
instructions like A =&A+B8, the operand A need to be 
referenced only once since tne format field in tne 
Piawnmiecouon indicates Now many times a particular operand i5 


used. 


E. MEMORY ORGANIZATION 

The term memory organization comprises two distinct 
aspects of a computer’sS memory. One is the hardware 
structure of the memory, while the other is the method by 
waren thewimemory can be addressed. 

In general all memory is structured linearly, differing 
only in tne number of bditsS per byte and the way a byte 15 
addressed. Memory is addressed throuen tne address pins of 


tne CPU, which are connected to the decoder, and translated 
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to addresses. Since there are no gaps in the sequence of 
numbers produced by tne decoder, any memory is addressed 
linearly. However, if you look at memory trom the users 


point of view, a memory is said to be: 


1. Linear if the user can address it linearly. 


2. segmented if the user can acdress olecks of 
linear address, where each space is called a 
segment. 


Bach item within a segment is addressed by a two 


component address: 


1. The segment selector which specifies the segment. 


2. The displacement which specifies tne offset from 
the base of the Segment to the item being selected. 


x < 


1. Mapping Segmented Memory 
In general, mapping is performed via tne segment 
discriptors tnat are maintained in the segment table. Fach 
segment nas a corresponding segment descriptor aeol tenet 
Contains the starting physical address and the length of the 
segment. This mapping is illustrated in Figure 3.19. 

The segment selector of a logical address is 
used as an index to select a segment descriptor in tke 
segment table. The displacement is added to the segment 
Starting address to produce tne physical address of 
tne op@rand being referenced. Additionally, displacement 


is easily checked by the hardware to ensure that tne 


reference does not exceed tne lenetn of tne segment. 
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2. Structured Memory 
Tne Intel 432 nas segmented memory whnica is 
different from the segmented memories On otner 
microcomputers as follows: 
1. The Intel 432 can address up to 2*¥*¥24 segments. 
Each segment can be up to 2**16 bytes long. 
Therefore, the total virtual address space 15 
2*x*4G bytes. 
2. The Intel 422 uses a two-step mapping process 
tnat separates segment relocation and access 
SOmtrRoOl . 
For these reasons Intel refers to tne 432°S memory as 
structured memory. 
Two-Step Mapping: The access mapping, deing Similar 


to one-step segment mapping process, 15 Pilustrated.§ in 


Figure 3.11 and it is performed as follows: 
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1. The segment selector part of a logical adaress 
is used as an index into tne access segment to 


select one of tne access descriptors, which 
contain access rights data. 


2. Tne access descriptor then acts as an index into 
the sezment table tome selec: a segment 
GESCripcor. 


5. The displacement is added to the sez2ment 
Starting address. 

Although there are several segment types, the two 

fundamental types, called base types, are tne data segmé@nts 


which contain both data and instructions, and the access 


segments, wnicn contain only access descriptors. kacn base 
mene is divided into several nardware recognized system .odd 
Pypes . For example, data segments are aivided into 


instruction segments and stack segments. 
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Figure 3.11 Two-Step Mapping. 
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Since two-step mapping process Separates Segment 
relocation from access control, tne type information is 
contained in the segment descriptor while the access 
information is contained in the access descriptor. This 
organization allows tne division of protection into user- 
specific protection (access rights) and segment-Specific 
protection (segment type protection). 

Each program module is supplied at run-time with a 
collection of segment numbers for only those segments it 
needs to access during execution. These segments determine 
the access environment and they are stored ina collection 
of access seements. 

The advantages one can view in the two-step-mapping 
can be summarized as follows: 

1. It takes fewer bits in an address to specify a 

segment (as few as four bits). 


2. It restricts tne number of segments accessibdle 
by a given proeram. 


3. ‘It separates tne protection features into access 

and type protection. 

One potential problem with the two-step mapping 15 
the access time. io speed up tne process, Intel 
maintains an associative cacne tnat stores recently used 
Segment descrivtors, access descriptors, and tne addresses 


of a number of commonly accessed items. 
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5. Object Rererencing, Addressing and Protection 


+ 


n either the single 58 the multiuser 
environment objects need protection from the user wno might 
inadvertently use an object ina way that it was not 
intended to be used and from programs that might destroy tre 
object. Additionally, in a multiuser environment when 
several users require simultaneous access to the same 
object, at least two more problems can arise: 


1. Access Rights: Not all tne uSers need to have 
tne same access rights. 


2. Exclusive access: One user may require 
Gremusivye access to that object for 4a particular 


Operation to ensure that no other processor 
amvers the sou jECiewhile tne operation procecds- 
These problems are solved in the 452 architecture by 
pees use of the access descriptors. 
4. Access Descriptors 
Bach object nas its own access descriptors wnicn 
aeG, €S Doth priviledge and protection permits fer the 
O@emect. Many access descriptors can exist for the same 
object. Each access deScriptor belongs to some (but may be 
copied and/or passed to another) procedure (context), and 
defines the acress rights of the procedure using this 
object. A procedure can reference a segment of memory if and 
only if it nolds an access descriptor for that seaement. Tne 


Base c Tients accorded the procedure by the access descriptor 


Can be read only, write only, both or none. 
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an object can be a contiguous subsection of a 
segment or it can consist of a single segment, or collection 
of segments. Figure 3.12 illustrates tne relation tetween 
segments and objects. 

Tne term segment refers to tne physical 
Structure of tne data in memory while tne term obdject refers 
to tne logical structure of tne data in memory. Viewing an 
odject as a Single entity, its root Segment specifies tne 
beginning of the object while the descriptor segment tnat 
Mernts to this root Seement is considered as pointing to tne 
whole object. Such a segment descriptor is called onject .pa 
reference, while tae se@ement table conteininge “oo ject 


references is called object table. 
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Figure 3.12 Relation amone Objects and Segments. 
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Be UOPERETING SYSTEM 
fne unique item in tne 432 arcitecture is tne wey 


its operating system is implemented. Tnere are two distinct, 





not self-complete but cooperating, operating Sy scents; sone. s 
implemented in hardware and is called the Silicon OS, -while 
the other is a collection of Ada packages available to the 
user for furtner modification as required, and called tne 
AMAX OS. Figure 3.135 illustrates the mechanisms implemented 
in tne Silicon OS and tne cooperating iMAX OS as well as tne 


conventional architecture level and the user interface 


level. 
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CONVENTIONAL Rete Sel et Got Ul Ros 


A number or resource management mechanisms are 
implemented in tne nardware, while the resource managment 


policies are establisned by software in iMAX OS. Tnese 
mecnanisms are wnat [Intel calls tne Silicon OS, whnicn 


consists of a memory resources manager and processor 
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resources manager. Tne m@€cnanisms supported by tne Silicon 
Bomere illustrated in fieure 3.13. 
2. iMAX OS 
The iMAX OS is a collection of Ada packages provided 
in two different subsystems. Tne users can select tne one 
best tallored to their applications: 

a. Full iMAX provides run-time support including 
dynanic storage management, aynamic process 
management, and I/0 interface. 

db. Minimal iMAX is asubdset of full iMAX anda 
Supports the execution ot multiple processes 


On a multiprocessor environment. It does not 
support dynamic storagze and/or process 


management and I/0 except through tne DEBUG- 
452 debueger. 
imemonly compiler sthat generates, code for tne 
4352 is the Ada compiler provided by Intel. Although this 
morces programmers to use only tne Ada language for writing 
meeerams running wnder the 432, it allows them to make Casy 
calls to the iMAX packagz®s by uSine the Ada provided 
facilities, sucn as tne Environment pragma, witn clause and 
use clause. 
iiwo kinds of processes can be controlled ody i1MAX; 
the Static processes which are created by the user at 
system initialization and tne dynamic processes which are 
created dynamically by the syStem and tnen entered into tne 
Ready state. fhe minimal iMAX, which does not support 
dynamic operations, requires only 47K of memory compared tc 


ee0e for the full iMAX. 
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The iMAX packages manage and enhance the 432’5 
interprocess communication, data transfers petween 
peripheral devices and the 432 central system, and allows 
the users to configure and control a number of General Data 
Processors and Interface Processors, static user processes, 


and I/0 device interfaces. 


GS. PROGRAM STRUCTURE 


In most computer systems program structure is part of 
the operating system or tne language run-time environment 
and there iS no need for tne program structure to de 
meemided In the description of tne architecture. However, in 
moe Intel 452, the program structure iS part ofr the 


mmcoitecture and contains tne following odjects: 


1. Processor Objects 
Zomeerocess Objects 

5S. Context Objects 

we instruction Objects 
5S. Dava Objects 


1. Processor Object 
ay previous section specified that the processors in 
a ile precessor environment are nardware-recoenized 
objects and that object is a data structure in memory. It 
iS logical therefore to ask how can a GDP, made of silicon 
and sitting on a pe board, where it fetches and executes 
instructions, be a data structure in memory? 


The physical processor is not an object. However, 


eacn pnysical processor does nave an ooject (a data 


ale, 





structure in memory) associated with it which is called a 
Ibepoces>Or ovject. The processor odject is an abstract 
representation of the GDP and is in one-to-one 
correspondence with the GDP. It can reside anywhere in the 
memory and can be dynamically relocated if necessary. 
Addressed by its associated processor via an On-chip 
reference, the processor object provides the means to asSsien 
tne processor it represents to a particular process set. It 
also Senve>s seo record information about tne physical 
processor such as its state (running or nalted), diagnostic 
information and references for other objects tne processor 
needs. Additionally, it contains an obdject reference Yor the 
process object CUPreEnLiyverunning on the “processor. [mis 
reference changes in time aS the processor sSwitcnes among 
Ser terent processes. The processor object is depicted in 
Figure 3.14 with the operations which act upon it. 

Remember that the GDP {s a tnree Stage pipeline 
processor which consists of two cnips, @acn one of which nas 
two subprocessors. If tne programmer tries to keep all of 
tnese details in mind as weli as tne flow of information and 
the data manipulation, while writing a program Statement, 
BomoLexity and confusion will reign. HOWeCVer, li eee 
programmer considers that a processor existS which can 


perform a set of operations, programming is simpler. 
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ewe enOCess UD;ECTS 


A process is a locus of control within an 


instruction sequence. That is, a process is tne abstract 


Send to processor-—--(inst)--—=>! 
i 


I 

t 7 

Broadcast to -------- (inst )---->! 
processor 
Read processor ------ (inst )----—>| 
status and clock { processor } 
Requalify process---~(nard)---->!} object 
1 ! 

! ! 

Select processor----- (nard )----> | 
t t 

t ! 

Start processor---=-- (hard )---~>| | 
t ! 

Create processor----— (soft )---=>| 
Nee er me a ane ee ae mae ee 


Legend: inst Oneraiwonme 1s ssa machine instruction 


(operator). 


hard = operation is performed ty nardware as 
4a result of conditions detected by 
the processor. 

soft = operation may be implemented vy 


software (e.g. an operating system). 


Figure 5.14 Processor Object. 


entity which moves through the instructions of & procedure 
as the procedure is executed by the processor. Given this 
Semenitiagm or a process octject, now can a se@auence of 
moerations be an object? DHE Process 15 9n0tT dn ODJECT, mum 
Cach process does nave an object associated with it which is 
Boeeed da process object. ERe Se process. 00j}eGeCt contaans 
information concerning now tne process snould be scneduled 


and wnat is tne process status (running, waiting, etc.). 
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The significance of tne existence and the use or 
tne object reference is tnat tne 432’°5 object oriented 
addressing and protection mechanism does not ais, a 
meecessor to access an odject unless it hasS an object 
reference for it. The object reference from tne processor 
object to the process object changes dynamically in time as 
the processor switches among different processes. Sach 
process has its own process object. The processes may snare 
the same processor. Figure 3.15 indicates operations on a 
mmecess object. 


read process clocKkess------(ints )---=->!} 
i 


| 
enter global segment------- Cima -—— process 
| 
| 
get state information------ (hard )----> | 
object 
save state information----- (nard)---=>,| 
| 
| 
der en eproces 5—-———-=—--— (nard)---=>! 


set scheduling parameters--~(soft)--—>| 


nam eee .8 aw OP ee OF | 82 ew ew wee FW eee Ew eee 


! 
eredtemprocess object------ (soft )---->| 


Figure 35.15 Process Object. 


Procedures (e.g. SQUAREROOT X ) are snared among 


several different processes by giving eacn process a copy 


(an instance) of the proceaure. Zach instance ot a procedure 


(eacn copy) is called a context. 
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A context object contains information about a 
particular invocation of a procedure. This means that tnere 
are aS many context obdjects for tne same procedure as there 
are invocations of tne procedure. The information tnat a 
context contains includes the instruction pointer tor tnis 
context, tne stack pointer for this context’s stack, the 
return link to the calling context, and reterences for all 
the objects that can be accessed by tnis context. 

meeure  O.160 depicts @ context object and tne 
operations which act upon it. The complete list of objects 
surrentiy accessible by tne procedure is called its access 
environment. The 432’s5 object-oriented protection mechanism 
Moes not allow a program to access an object unless it has a 
Zeorenee fOr that object. Thus in the context one can only 
access objects that are listed in the access environment, 
meee tne access e@Environment cnanges only if tne current 
context calls another procedure because tne called procedure 
Pormecemmcirte Tent Context and nence a different iist oc 
objects that can be accessed. This places the protected 
a@eess @nvironment at the procedure level, instead of the 
Beocess Or job level aS On most systems. 

4. Instruction Onject 

An instruction e) (8) i iete 18 nas two major 

Cmaracteristicss: 


iit "can only hold instructions (and a“iirrile 
bit of system information) and never data. 


ahs, 





2. It is tne only type of object tnat a 
processor Wii use as a source of 
instructions to be tetched and erecuted. 


Call--------- Sn ane 


{ 
Call with message---(inst)----->! context 
] 


j 
ReMi = ————— mmm (inst )—————>!} 


eee ae ee ee ee ee ee ee ee ee ie ee ee ee ee ee oe 


| 

objec 
eect con Cex t—-—=——— (inst )----- >! 
ebiect ! 
Create context------ (Hand )}==--—> | 
data segment 
Ureate ope rand------ (nard )----- >! 
Stack | 
Pesumoue Context ----— (nard )----- >! 
{ 
| 
I 


Garbage collection---(soft)---=> 


Dipinenogto. COntext Object. 


This second feature implies tnat the 432’s5 
object-oriented protection mecnanism will never allow any 
other kind of object (proccess object, data onject, etc.} to 
be accidentally mistaken for instruction and thus ©#x2cuted. 
moe tooldtion of tne instructions provides tne advantage 
that all 452 programs are fully reentrant. 

iisim te FiOmg = OD}ECtS Can be Sharea by ‘several 
instances of a program. Figure 5.17 indicates an instruction 
mc epeanras the Operations woich act upon it. 

5. Data Objects 
Data object is an object tnat holds data (¢.@2. 


integers, reals, cnaracter, tables, etc.). Tne 432 provides 


a mechanism for assigning tata objects (as well as other 
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objects) a software-defined type. Tnis is anotner protection 
mechanism which ensures that tne onoject will ve manipulated 


by instructions of the proper type. 


Call context---------- (inst )--=>! 
| ] 
| ] 

Call context---------- (inst)--->! 

with message | instuction 

Return am GED ED GR- te OE ee ome Ge ce oe = oe ce (inst)--->! 


Branch intersegment---(inst)--->!} object 
! 


! 

Branch intersegement---(inst)-—-->! 
and link 
Brancn intersegment---(inst)—-=->| 
without trace 
Peete = ——————— (nard)—-->) 


—— Fe ee ew ee EP mee ee eee ee ce ee ee Ee oe oe oe ee 


! 
eetema a= —— = ———————— ee) aa 


Figure 3.17 Instruction Object. 


S. Summary of the Structure of a Program 


Figure 5.18 summarizes the important points 


mpout Edenh obDjJeC@ct of tne program structure. 


He. INTERPROCESS COMMUNICATION 

It has been said that one of the salient characteristics 
Seeetneweoc 15 1tS Capability to support multiprocessing ina 
multivrocessor environment. In otner words tne system 
provides for concurrent programming. The mechanisms that 
Eeopeorueconcurrent programming are quite complex and include 
the use of Communication Ports Objects, Domain Objects, and 


mespateaine Fort Objects. Following an explanation of tnese 
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Tne abovelar 


Figeure 


Physical Processor 
—Made of Silicon (not an onject) 
-Fetchnes and Executes Instructions 


Processor object 
-~kacnh processor has one 
-Gontains information suco as: 
—-Processor Status (eg, running, nalted) 
-Diagnostic and macnine cneck intormat. 
moenrenhence for the process scunmrent ly 
belingwexecuted 


Process Onject 

-One for eacn process in the system 

—Contains information such as: 
-Process status (eg, running, nalted) 
-How tne process snould be scneduled 
“Reference for the context currently 

beine executed 

Context Object 

=UNemperecacnh instance 6 fPeamorocedure 

—-Contains information such as: 
SIMSON porn ter {Ore Enms object 
-Stack pointer for tnis context’s stack 
-Return link to the context’s stack 
SKomenencemaor ail the OOJECtS that Can 

be accessed by this context 

Postunmueulon ODIECT 

-Contains only instruction and no data 

~lteromeune OnLy type Of OD ject that. 4 
PROeeSSGmeauocomas a SOUrCe Of 
instructions to be tetchea and 
Caecu t ed 


MR WHe Nardware recocni zed od}Eects 


Data Object 

-Contains Data (eg, integers, reals, 
enaracters or 4 @Ombination or several 
primitive data types) 


3.18 Summary oft the Program Structure. 
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BeyectS;, e942 Simplified example will be presented for a 
general understanding of the mecnanism that Suepor Ls 


Pemeurrent programnine. 
1. Communication Port 
A communication port is tne communication medium 
between two asynchronously communicating processes. Each 
communication Dont ls represented DYyieoan oOb)ect which 
contains information on messages that are sent to processes. 


Figure 3.19 indicates operations on a scommunication port 


object. 
a (tists ! 
! ! 
| 
Conditional penteee === = (nen =—— 5 | 
! communication | 
Surrogate send---------- (inst)--->! 
port 
Recetvecrae nen nn (inst)--=>} 
' ~opject : 
Conditional receive-----(inst)---—>| 
| 
Surrogate receive-----—-- (inst)--->1 | 
| | 
Message bufrere--e---- = (hard )--=>} 
full cneck | | 
Enqueue message--------— (hard)--->| | 
| i 
Bnaueue carrier-------—~- (Had vie—— 7a 
to port ! 
eee... —————— (sitet )—=—> | 
! | 
| I 
Priority messageq------— (sott)—-=>| 
enqueue : 
Multiple waito-c-------- (Sie: Jay | 


Figure 3.19 Communication Port Object 
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me communication ports, by acting as a buffer 
between two asynchronous processes, allow eacn precess to 


proceed at its own rate. 
2. Domain Objects 
Inbedded in the features of Domain Objects are the 
concepts of static and dynamic objects. Tne concept of 
dynamic objects has been already encountered in Section G.3, 
wnere the context odjects are examined. Recall that the 
eccess environment consists of objects for wnich an object 
Memerence exists in the list of the current context obdject. 
Additionally, tne access environment changes dynamically 
wnen a procedure is called by a context and the access 
Environment is now the list of the new current context. 
Since the Gees ts —saccessivle by » the process cnange 
ayecamicalzy in time, the odj@cts pointed to by tne current 
Pre reOUV,eECL Vanyein time. [nerefore the space they occupy 
in memory is tdeatlocated once tney are not accessible by the 
Mmoccess, stence these objects are dynemic objects. Ina 
Semtrdst Static obdjects are thoSe whose memory Space is 
never deallocated regardless of wnetner they are accessible 
Sueenot. sin summary, 4 context object is also a tLlist of 
dynamic moyects wWoile a domain is. a list of object 
references for all tne static objects used by 4 module. 
In the object-oriented decomposition method, the 
Smererion for modularization is for eacn nodule to Alae a 


Seeeenoseecision. In order to camry out its task, a module 
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meant Consist of "more than one procedure whicn in turn miegnt 
feeoeveecdecess Some, all or none of the static obdjects used 
by tne module. Tnis is tne reason a domain contains a list 
or object references to all static odDjects of the module. 
The reason objects associated with the modules 
peewcaltec donains is that tne module they represent confine 
Beowiledse of the object structure within a specified domain. 
mere o.20 d@picts 2 domain object and tne operations wnich 


met upon it. 


Call contextq--------------- (inst)--->! 
' domain } 

Call context--------------- (inst)--=>| 
with messaze 
Ole (inst)--->i object | 
| | 

Create contex tooo t oor (nard)-—->| ! 
! ! 

Create domain-o----------- —(soft)--->} 


Preure o.-<co Domain oo ject. 


Networks of domains, where C€ach domdin nides tne 
Presentation of an object, represent the static structure 
of a 432 program. Some ot tne domains make use of objects in 
other domains in the network to create a more complex 
OO eect. 

If a module (represented by a domain object) 
meéeds to use procedures provided by anotner module, tne 
first module must have a reference for the domain that 


represents the second module. The domains can be viewed 


oe, 





eitner from an outside or inside point of view. Consequently 
meoceayres can be executed inside or outside of tne domain, 
this prevents static objects of the domain from beine 
accessed by all procedures tnmat use this domain. 

In this case tne static odDjects are divided as 
follows: 

ine) © rivate Opne Cc CS a> accessible only by 

HLOGceaurTes Inside “[re-=doudin. 
Be Public objects = accessible by procedures 
Ope Lost ae ang outsiae The domain. 

Let us assume the Situation where a procedure 
(of a module) is currently executing. This procedure uses 
Pieee same GOmdin oObjJE€ct which represents tne module that 
belongs to the procedure. [n this case we say the procedure 
mrmomeacitume 1 nSide the domain. Tne same procedure needs to 
make a cali to another procedure not belonging to its 
module. For tnis to be achieved tne first nodule must nave a 
reference to the domain representing the module of tne 
omeree. ATter this object reference is establisned the 
caller can use the Static objects only in the public domain 
of the callee. In tnis case tne procedure is executing 
outside the domain. 

5. Dispatcning Port Objects 

Doe dtSpavening “port =Object consist of ~~ two 

queues tnat serve to matcno processes with processors. It is 


the object that is used to implement transparent 
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eeti processing. Fieure $§.21 Indicates a dispatcnine port 


eee ands the operations which act upon it. 


Dispatching port———~-—— (nard )---> |} 
| «dispatching 
Scnedule process—-~-----(nard )--—> | 


object ions & 
Enqueue processor-—---(nard )--->} 
object object 
Create dispatcning—----(soft)--->| 
DOPG 2 a a a a ee a a 


Figure Sec levispetebine FOrty Ou Tec. 


= 
{iz 


xanple ot Interprocess Communication 

Consider a program, CHAT, which consists of two 
Subprograms TED and JOHN. Program TED writes a report and 
then sends it to program JOHN to type it which in turn sends 
mepcadckmuoml eh) Tor proofreading. When the report is correct 
M20 prints it. 

Tne subprograms TED and JOBN will be tne _ two 
processes of CHAT wnich can start execution independently in 
mero 2irterent processors of tne system. For simplicity let 
memeeconside@mathat TED starts execution first and begins to 
write its report. Wnen it is finisned, JOEN nas »deen 
executing and it iS ready to recieve TED’S report for 
typi ne. 

Tne mechanism tor sending the report trom TED to 
JOHN is the communication port wnlcn acts as a buffer 
between the two asynchronous processes, allowing @€acn to 


proceed at its own rate. Two communications ports are needec 
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for our example. One is TED’s receiver and JOHN ’s 
Peesmarter while the other is JOHN’s receiver ana TED’S 
transmitter. rere o2ce = Joiustrates the “communication 


between TED and JOHN. 


| COMM. 8 \ 
0 een ee ee — 
creep \ | TED “Ss \Sidrame — X 
! i reports / | receiver / | reports / 
i I 
SS ee / wo 2 a || | 
! PORT / 

eee eC Ne NN eS I 
| 1 
eS Des | JOEN’s | 
! | object | | opnject | | 
nao ant Sy ye sy ay Wy). ogo; ee | 
/ COMM. 
Oe eC a oe 
/ typed i/ JOHN s | / typed | 
\ reports ; \ receiver | \ reports | | 
I a Set Soir ama | 
\ PORT 
i I 
' 1 


Pmeure o.c2e Interprocess Communication 


Tne processes TED and JOHN interchange messages 
wae tne “ConNunication ports and the operations SEND and 
RECEIVE defined on the communication port ooject dear the 
Peepeen Of that intercommunication. 

Tne instruction SEND nas two operands. One is 
the message itself and tne otner is tne communication port 
where the message is beine sent. Before the SEND is executed 
tne process nas a message it wants to send. After SEND is 


executed, the message naS been Sent to tne specified 
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communication Port. Hom -etticteucy, Onlye=tne object 


reference is copied. 

The RECEIVE instruction nas one operand, tne 
communication port where tne message is to be received. 
Before RECEIVE is executed there is a message waiting in the 
communication port. After RECEIVE is executed, tne message 
75 moved from the port to the process executing the RECEIVE. 
Again only the onbject reference is copied. In tne case a 
RECEIVE instruction is executed witnout a message in tne 
communication port, tne process waits until a message is 


Sent. 


Mm A BASIC I/0 MODEL 
aoogaerecomplicated mecnanism in tne 432 arcnitrecure i1s 
the I/O operation. Here we examine the basic means for 


Perrorming an 1/90 operation as well as tne very obdasic 
implementation mecnanisms needed for I/O operations. 

A peripneral subsystem is an autonomous computer system 
With its own local memory, 1/0 devices and controllers, at 
least one processcr, and software. The number of peripheral 
Subsystems employed in any gzivén application may te varied 
with changing needs, independent of the number of GDFs in 
Ene systemn 

Peopopommport the transfer of data through the wall that 
Separates a peripheral subsystem from the main system, tne 
Interface Processor (IP) provides a set of software- 


Somer rolleac windows. Aw window is used to expose a single 
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Doect lm Main SyStem memory SO that itS contents may be 


transferred to or from tne peripneral subdsystem. 


‘Service Reply! ‘Service Requested} 


| 
Message Message 


_= am a ee oe eo ee A ce, a ec Ga > Pep an we aw SS a Oa ss a ee 


(i ! _—————— 


Peripheral | 
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Figure 3.23 Peripneral Subsystem Interface. 


The IP also provides a set of functions that are invoked 
ioe soutuware. “They generally permit objects in main system 


memory co be manipulated as entities, and enable 
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communication between main systen processes and software 


executing ina peripheral subosystem. Figure $3.23 snows tne 


Peripheral subsystem interface. 

A device interface is considered to be the hardware and 
software in tne peripneral subdsystem tnat is responsible for 
managine an I/0 device. A message sent froma process that 
needs an I/0 service contains information that describes the 
Tequested operation (9.g. ‘read tile XYZ"). The device 
macverface interprets the message and carries out the 
operation. If an operation requests input data, tne device 
interface returns the data as a message to the originating 
Mmecess. tne device interface may also return a message to 
positively acknowledge completion of a request. 

Meemmir is connected to the peripheral suodsystem bus as 
if it were a memory component; it occupies a blOcK of memory 
addresses up to 64K bytes tone. Figure 3.24 illustrates the 
peripheral subsystem nardware. 

The Attacneid Processor (AP) and the IP interact with 
Sach otmer by means of address references generated by tne 
me ara P@rterrupt requests generated by the [F. At any given 
tame, the IP controller is represented in main memory by a 
process object and a context object. Like a GDP, the IP 
maselo I's represented by 2 processor object. 

Wnen supporting multiple process environments, the IP 


controller selects tne environment in wnicn a function 15 to 
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Figure 3.24 Peripneral Subsystem Hardware 


ve executed. If an error occurs while tne IP controller is 
Seecutineg» a function on behalf of one device interface, that 
error is confined to the associated process, and processes 


associated with other device interfaces are not affected. 


Ke. WINDOWS 
Every transfer of data between the main system ana 4a 


peripheral subsystem is performed with the aid of an I[P 


ve 





spa — 





window. A window defines a correspondence, or mapping, 
petween a subrange of peripneral subsystem memory ile oot 
within the range ot addresses occupied by the IP and an 
object in main system memory. 

The action of the IP, in mappine the overiphneral 
subsystem address to tne main system object, is transparent 
to the agent makine the reference; as far as it is 
Concerned, it is simply reading or writing local memory. 
Since a window is reterenced like local memory, any 
individual transfer may be petween an obdject and local 
memory, an oodject and a processor register, or an odject and 
an I/O device. 

There are four IP windows that may be mapped into four 
different objects. The [P controller may alter the windows 
auine e€xecution to map different subranges and objects. A 
fifth window provides the IP controller with access to the 
IP’s function facility. By writing operands and an opcode 
into predefined locations in tnis window’s subrange, the IP 
controller requests the IP to execute a function on its 
behalf. Upon completion of the function, tne IP provides 
mearis oinmrormation that the IP controller can read through 
toe window. 

Beeecesw there 1s a finite number of windows, most 
applications will need to manage tnem as scarce resources 


that will not always be instantly availaodle. This means tnat 





at least some I/0 device transfers will nave to ve buffered 


{in local memory until a window becomes available. 


L. TRANSPARENT MULTIPROCESSING 

The Intel 452 is especially desiened to support parallel 
execution of programs by multiple processors. Absolutely no 
software changes are required tO move programs trom single 
processor systens to multiple processor systems or vice 
versa. 

The first advantage of transparent multiprocessing is 
flexibility provided by a macnine that o fers a range orf 
performance. Processors can be added to or removed from 
the configuration to meet the desired performance or price. 
The s@€cond advantage is reliability, because if one 
processor ftaiis, the rest of the system may be able to 
Continue runnine. In fact, during a benchmark performance 
mectee One siot in tne system motnerboard prevented an 
assigned GDP from being initialized and the system continued 
to execute. 

Tne effective nanagement of multiprocessing ina 
muntiproecossor environment Fequlres Policy Making, 
pesecduling, and Dispatching. 

dono. Cyr Making 

Policy Making @stabie snes the Criteria @that 
determines how processes snare processors. These criteria 


are iefined by tne user, via the iMAX OS, at system's 
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initialization. The iMAX OS passes this information to tne 
Silicon OS for implementing tne policy mecnanism. . 

Options tnat can be selected to implement 
processcr sharing are first - come - first - serve (FIFO), 
round robin, priority, and deadline weignted. Tne user can 
select tne one which meets the applications reauirements. 

Tne Policy Making requires tne user to set 
the scheduling parameters Dy anSwering questions sucn as: By 
when must the process be completed? How long does a process 
PeearGe One toe processor? How many turns can a process nave 
vefore terminatizg? 

Dy Ge Se lej cl aco iby lolz 

scheduling is tne ordering of processes t0 
mn on processors in a manner that realizes the policy. It 
is part of the mechanism that carries out the policy. 

A process is scheduled “dy sending® tae 
Mrocess tO the dispatching port in the form of a message 
memyece. once in the queue, the process waits for a processor 
mer @zxecution. 

Cz bispatcni i2 

Dispatching is the assignment of processes 
momeprecessors in the order in which the processes have been 
scheduled. 

The meeting places for processors and 
Mrecesses are the Dispatcing Ports where the the orocesses 


Stand in line waitine for service by 4 processor, and 


fare. 








processors gO when they need a process to execute. Whenever 
a processor needs a process to execute, it simply removes 
the first process in line at its dispatching port and begins 


to 2xecute it. 


2. Dispatcing Ports and Program Structure 

We nave seen tnat tne dispatcning port objects are 
closely related to the processor object and process object 
whicn are part of the program structure. Tnis relation must 
femeeweil Controlled in order to prevent perturbation of tre 
program structure. 

For example the network required to pertorm process 
scheduling and dispatching is complex. To Keep track of 
Prese asSSignments two things must be accomplisned. First, in 
Paene processor object there 1s @ object reference for the 
processors dispatcning DOLL. wnicn means that eacn 
processor has only one dispatching port. This information 
forces a processor to always visit tne same dispatcning 
Memoeweeoecond, in @ach process object there is an object 
reference to the dispatching port the process is allowed _ to 
wesit) and thus, a process can visit only one dispatcning 
port. We can conclude, therefore, that by naving one 
dispatcing port per processor and process tne 
multiprocessing task of the 452 can be accomplisned witnout 


major effort otner than assigning tne proper policy making 


parameters. 
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This chapter has presented the characteristics and 
advantages Ox tne baie d 452 over Sonat aaa 
microprocessors. Altnougn this chapter is long and at times 
detailed, it presents tne reyuisite information necessary to 
understand the results observed in the Benchmark Performance 


Chapter. 
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IV. MULTIPROCESSOR/MULTIPROCESS BENCHMARK PERFORMANCE 


In general the Benchmark Performance Test was conducted 
using the Benchmark programs generated in Applegate ([Ref. 
So} s modified as required to execute in tne 
Multiprocessor/Multiprocess environment. Initially, the test 
worm COnducted with only one processor and one process in tne 
system to confirm tne results reported in Applegate [Rer. 
3}. Tnen, using the same Bencnmark Programs, tne test was 
performed wie two processor/processes, three 
processor/processes and finally four processor/processes in 
the system to determine if the 432/574 system is capable of 
SuStaining incremental performance improvements as 


mmoicessors are added to tne system. 


A. BSNCHMARX PERFORMANCE TEST 

Kodres (Ref. 12] analyses multiprocessor systems that 
uses a common shared memory. Although devendent on tne tyve 
Br instructions being executed, it was snown tnat if tne 
programs are fetched from common memory, the systems odus 
becomes a bottleneck with only two processors in tne system. 
To determine if the INTEL 432/670 system could de ettective 
witn six processors as reported in the Intel manual (Ref. 
13], a series of Eenchmark performance tests were conducted 
using seven programs from the Computer Family Architecture 


Study (CFS) (Figures 4.1 - 4.4), two orograms from a 


Ce 





performance comparison conducted by the University of 
California - Berkeley (Figure 4.5), and two programs tnoat 
executed instructions at opposite ends of the iAPX 432 odus 
activity spectrum (Figure 4.6). All Bencnmark programs were 
executed with the operating system configured for the 
default service period (DF) and again with the service 
period set to infinite period count (IF). Each figure 
depicting performance contains tne name of the Benchmark 
program, tne number of iterations, and tne number of seconds 
requirec to complete the execution as well as tne curve 
snowing maximum theoretical efficiency, observed performance 
for tne infinite period count (IF), and default (DF) service 
periods. Additionally, calculated efriciency numbers 
Seooctaved With C€ach system configuration are included on 
the right side of the grapn for easy reference. 

Each program was executed witn tne INTEL 432/67 system 
configured for one processor. A second processor was 
emoralled) and two processes containing identical Bencnmark 
programs were timed during execution. Processors and 
processes were added incrementially up to and including four 
1APX 432 General Data Processors (GDP). In general the tests 
snow tnat tne INTEL 432/678 systen was still performing at 
approximately ninety percent etficiency with four processors 


in tne systen. 
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B. “RESULTS 

Since Kodres (Ref. 12] predicted serious bus contention 
Mueeuwo processors and the observed performance is still at 
approximately ninety percent with four processors in the 
System, additional analysis was performed uSing a Logic 
State Analyzer to observe systems bus activity while 
Peccupunee instructions at opposite ends of tne bus activity 
spectrum. FEencnmark programs were designed and implemented 
moray execute tne MOVCH instruction to represent tne nign end 
of bus use density and DIVORD to represent the low end of 
wus activity. 

Shoop [Ref. 14], considering a system bus widtn of 
weereen  DIitS and 4 nigh transfer speed, predicted tnat tne 
MOVCH instruction would take 18.4 microseconds to execute 
wnile the DIVORD would require 29.6 microseconds. Using the 
Logic State Analyzer delay function and triggering on a 
Known adaress, a series of program executions were performed 
momeenetrate a bus activity Snapshot of 6540 microseconds. By 
Gounvigae the number of bus access cycles and tne number of 
execution cycles, the relative efficiency of tne [ntel 
432/578 computer system was calculated for one tnrouvugn 8 
processors using the equation derived by Xodres [Ref. 12]: 
taagre Cae depicts tne predicted and experimental resuits 


for tne weven and DIVORD instructions. 
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Re = (B + HE) / (NB + I) wnere Re = Relative efficiency 
B = Bus activity cycles 
E = Execution Cycles 


I = System’s Bus Idle 
Time 


N = Number of Processors 


To determine if the data egatnered during the Bus 
Snapsnot Dem Lod was representative of tne Benchmark 
performance executions, tne instruction execution times are 
compared in Table 4.1. There is a small aifference in 
execution tines measured by the bus activity Snapsnot as 
opposed to timing the repeated execution of tne instruction. 
Since tne timing is accurate to tne nearest second, tnis 
Small difference can be attributed to measurement error. The 
meer aa¢ference between Shoop predicted execution times 
and measured execution times can be attributed to an overly 
motimistzie prediction by Snoop. 

rrom the calculations displayed in Figure 4.7, systems 
executing instructions consisting of MOVCH would begin to 
saturate tne svstem’s bus at 4.3 processors wnile DIVORD 
instructions induce the bottleneck at 7.7 processors. Since 
the execution time of DIVORD is greater tnan MOVCH, it 
follows that the predicted bus contention snould be less for 
tae DiIVORD program as observed. Since tnese instructions 


represent bus activity at opposite ends of the bus activity 
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spectrum, Ht appears thay the  Imtel s design of ssix 


Mmocessors per system 1s an appropriate cnoice. 


oe PMNALTS IS 

PRESS cxpianation for this performance improvement over 
that observed in other Multiprocessor/Multiprocess systems 
tnat fetcn programs from common memory is tne INTEL 432/670 
system has a 32 bit syStem’s bus. The 32 bit system’s bus 
nas a maximum of 77 megabits per second transfer rate 
compared to about le megadits per second for a typical 16 
vit MULTIBUS system’s bus. Additionally, tne instruction 
formats used by tne iAPX 4352 processors are designed to 
reduce the number of bytes transferred. Finally, by using a 
byte addressable boundary ratner tnan @ word boundary, tne 
number of bytes that must be transferred when a processor 


fetcnes instructions is reduced. 


Sec 





CHAR } 


ITER, 100 060 


363 


323 
340 


314 
326 


TIME SEC, 


CHAR 2 


ITER. 100 000 57 


138 
141 





TIME SEC. 


Figure 4.1 CFA Benchmark CHAR Perrormance. 
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Figure 4.3 CFA Bencnmarsx DECOM Performance. 
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Figure 4.4 CFA Bencnmark EASH Performance. 
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Figure 4.6 MAX/MIN Bus Activity Benchmark Performance. 
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Figure 4.7 Predected and Actual Processing Performance. 


Table 4.1 Instruction Execution Times (Microseconds). 


INSTROCTION 432/570 BUS S HOOP 
OBSERVED SNAPSHOT PREDICTED 

MOV CH 12.4 IZ Ele 10.4 

DIVORD oc.0 Ag 3 29.6 
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ue CONCLUSIONS 


= SEP ae SE ae Se eee ee SO Gee 


The excessive execution overhead resulting trom the 
Intel 452 object oriented arcnitecture nas prevented tne 
Intel 452 from demonstrating superiority when comparing its 
opeed ox execution to otner microprocessors den a 
Uniprocessor environment (ie., one processor witn itS own 
memory and systems bus). For example wnen compared with the 
Motorola 68@¢¢ and the INTEL 8@86, tne iAPX 432 provided 
approximately one-half the througnput [PATTERSON]. 

Benchmark performance depends neavily on tne instruction 
set being executed. Since individual systems use unique 
metnods of performing certain operations, average Bencnmark 
figures could be misleading if the System was to be designed 
for a specific application. For example, if the instruction 
set required was predominately Floating Point operations, 
the INTEL 452 performance snould be superior because of its 
efficient Floating Point nardware. 

When comparing a computer’s ability to perform in a 
Multiprocessor enyironment, Instruction mix  i¢ stiil 
important but you must also consider the bandwidth of the 
meMOTY « Tnere are three types Od Multiprocessor 
architectures that effect the bandwidth characteristics ofr 


Multiprocessor systems: 
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1. Program and data stored in global memory where 
all processors nave equal access. ; 


2. Program stored in a local memory isolated to 


access only by the parent processor. Data would 
be stored in global memory. 


5S. Same as system 2 except local memories are also 
accessible by otner processors tnrougn a Crossbar 


Swatch . 

The Crossbar Switcn is a system tnat enables tne desiener to 
increase the number of system buses to tne point wnere there 
is a s@parate patn available for eacn memory unit. Its 
obvious advantage is to eliminate the system bus contention 
when operating in a Multiprocessor/Multiprocess environment. 
Since many real-time applications programs reside in elodal 
memory, tne Bencnmark test were conducted in the global 
memory stored program environment. Processing power of a 
system of computers sharing a common systems bus, is 
measured in relative efficiency (see Cnapter IV. 28.). Eacn 
processor must be able to process the program steps and data 
witnout interfering with eacn otner by saturating tne system 
bus with request for instruction and data fetches. 

Analysis of the INTEL 432/670 system Benchmark 
performance test show that tne relative efficiency of the 
system PseStlll approximately “ov percent with four 
processors in the system. Tne effectively maximum number of 
meocessors is confirmed at six. This is in sharp contrast to 
an effectively naximum of two processors for tne INTEL 8086 


operating witn a MULTIBUS systems bus [KODRES]. Again it is 
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emipuasized that tnese performance figures are base@ on a 
common memory stored program syStem. 

Althougn this tnesis was not concerned with transparent 
multiprocessing, tne advantages of a SyStem that Supports 
this concept was evident. During Bencnmark program 
executions, a processor was prevented from being tnitialized 
due to a loose piece of plastic in the motnerbdoard card edee 
connector. The system continued to function automatically 
sequencing the extra process into the diSpatchine queue. The 
aerudt failure was only discovered when attempting to 
determine a Sudden increase in execution times. 

Benchmark programs for this project were written in the 
Department of Defense programming language Ada. Previously 
generated code was found to be self~documenting, easy to 
modify, and interfacing problems were non-existant. Altnougnh 
Ada has been cited aS a complex language, the ease with 
which it is nodified combined with its strong tynine 
eiaracteristics, and readability conrirms its ability to 
support the Software kEngineering principles. 

While tne effectively maximum number of processors for 
general purpose computing in the INTEL 432/678 system is 
comfirmed at six processors, incorporating tne iAPX 452 into 
a Crossbar Switch system could produce a system capable of 
SUpPperting up to 5@ processors. bis, di rect military 


application to tactical systems requiring 4 growtn potential 
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ms Gmciting particularily when considering the ability of the 
mere 402 tO SUDpPOTt transparent multiprocessing. . 
Since current Navy microcomputers such as tne AN/AY£-7 
cannot be expanded beyord four processors without reauirine 
major restructuring of tne existing software, it is 
recommended that a follow on study be conducted to determine 
if a large system is feasible using tne 1APKX 4352 in a 


Crossbar Switch system. 
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APPENDIX A 


1APX 452 VS CONVENTIONAL MAINFRAMES 
This appendix provides a comparison of tne i APX 432 
Architecture and the Architecture ofr Conventional 
Mainframes. 


LAPX 432 
' Architecture Architecture 
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J 
evaluation | imemory 
| I 
Primitive data ‘Characters, ;}Characters, unsigned 
types ‘unsigned intevers;integers, integers, 
‘integers, reals jreals, temporary 
ireals 
Floating point ;yes (Yes 
hardware 
Addressing modes :Some modes not ‘Symmetrical: all 
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}operands fevery operand 
PROGRAMMING 
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Paltocetat ron imechanisms in 
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APPENDIX B 


PIN DESCRIPTION 


This appendix provides the pin description of tne iAPX 
432 general data processor. 


4620) Fin Mescrm@ption. 


Processor Packet Bus Group. 


ACDI5~ACD@ (Address/Control/Data lines, Inputs, hien 
asserted). 
PRO (Processor Packet bus Request,Input,hnign asserted). 


ICS (Interconnect Status, Input, high asserted). 
Intra-GDP Bus Group. 


Ul15--UI@ (Microinstruction Bus lines, Outputs, high 
asserted). 


IS6---IS2 (Intercnip Status lines, Preps , nign 
asserted). 


System Group 


FATAL/(Fatal, Output,low asserted). 
ALARM/(Alarm signal,Input,low asserted). 
INIT/(Initialization,Input,low asserted). 
CLR/(Clear,Input,low asserted) 

Hardware Error Detection Group 

Master (Master,Input,hbigh asserted). 
HERR/(Eardware Error,Output,low asserted). 


Clock Group 

Seok Ghee (Clock &, Clock 3, Inputs). 
Testing Input 

RDROM/(Read ROM,Input,low asserted) 
Power and Ground Connections. 

VCC (4 pins). 

GND (5 pins) 


VBB (Internally Generated). 
N.C. (No Connection, 4 pins) 
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@ocVe Pin Description 
Processor Packet us Group 
PRO (Processor Packet request, Tnree-State Output, nigh 
asserted). 
ICS (Interconnect Status, Input, high asserted). 
Bout (Enable Buffers for Output, Output,nign asserted). 
Intra-GDP Bus Group. 
uli5<-ul@ (Microinstruction &us Poem eS7, Inputs, nign 
asserted). 
IS6-IS@(Interchip Status lines, Outputs, high asserted). 
System Group 


PCLK/(Processor Clock, Input, low asserted). 
CLR/(Clear,Input,low asserted). 


Hardware &rror Detection Group. 
Master (Master, Input, nign assered; 25k nomonal oullun 
Reese ot Open Drain Output, low asserted). 
Clock Group 
Seem, CLAS (Clock A, Olfock B, Inputs). 
Power and Ground Connections. 
Voc (Power Supply, 4 pins). 


GND (Ground, 5 pins). 
Wee (Nomconnection, 7 pins). 
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APPENDIX C 


SAMPLE PROGRAM LISTING WITH SUBMIT FILES 


This appendix contains all the necessary files to 
generate Multiprocessor/Multiprocesses environment. 


=-NChAMoL | package specification 


-- This is the ADA Specification package for the 
—~- CFA character searcn bencnmars. 


=— Coane 1 


package SCHAR is 
sudtype sudint is integer range 1..256; 
Pypemtstarray is array(1..256) of caaracter; 
arrayl,arraye : txtarray; 
procedure SEARCH(srchlen,arglen : IN subdint; 
arrayl,arraye : IN txtarray; 
lige, soln eintessr); 
end SCHARF; 


ao) CHAIR | package pody 


“-- Tne following package contains the procedures needed to 
—- implement the CFA character Searcn bdenchmark. Procedure 
——- SHSARCH performs tne actual searcn as desired by tne CFA. 


ssid Cel Bes) ol 


pragma environment(”"ACS:TEXTIO.MLE’, INTIO.MSE”, ; 
"SCHAR.MSE )3 
Wito teas eyO,tht1o;, use text_io,intio,ascii;s 
package body SCEAR is 
procedure SEARCH(srcnlen,arglen : IN subint; 
apbrayl,arraye : IN txtarray; 
loc : OUT integer) is 


25 





i,j : integer; 


=; 
while i <= srcnien loo 
if arrayi(i) = Bey ln tnen 
if j+tl <= arglen then 
i := ji+1; 
j s= jrls 
else 
ele 2 at 
Cxits 
end if; 
else 
LB Stale 
5 er 
end if; 
end loops 
end SEARCH; 
end SCHAR; 


package USER PROCESS 1 is 
procedure MAIN; 
end USER PROCESS 1; 


package USER PROCESS_e2 is 
procedure MAIN; 
end USER PROCESS 2; 


package USER _ PROCESS 3 is 
procedure MAIN; 
end USER_PROCESS _3; 


package USER PROCESS 4 is 
procedure MAIN; 
end USER_PROCESS 4; 
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pragma environment( ACS:TEXTIO.MLE’, INTIO.MSE , SCHAR.MSS , 
“PRIMAIN.MSE™ ); 
with text_io,intio,schar; use texrt_io,intio,scnhar,ascil; 


am Viiineecdeso includes time for procedure 
— invocation 
a 5 May 1983 


package body USER PROCESS 1 is 
procedure MAIN is 
eco rcne 1c co,Srecnh arg,timer loop : integer; 


begin 


== sionbenia Lization 


arrayl <:= Gaviewuso . 0s doa ae oy sy ieee cele: oe 
Gove 7". t ed ee Gani OMe oy. 6 , 
otners => ~ “); 
ainavees= ( dd. a, y ,othners => ° °); 
srcn_lenegth := 22; 
Sele elie s s= 3; 
timer _loop s= 108¢@C¢; 
pitmect Start of Search...1 ); 
put (BEL); 
put(BEL); 
put(BEL); 
put( BEL); 
put(BEL); 


for iini.. timer _loop loop 
SPARCH(srch lenetn,srchn arg,arrayl,array2,loc); 
end loop, 
put 2¢( end the search.....1 )} 
put (BEL); 
put( BEL); 
put (BEL); 
put(BEL); 
put (BEL); 

end MAIN; 

end USER _PROCESS_1; 
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PREMAIN.MBS 


--CHARSi driver routine 


pragma environment("ACS:TEXTIO.MLE’, INTIO.MSE”, SCHAR.MSE’, 
PROMAIN.MSE ); 


with text_lo,intio,schar; use text_io,intio,scnar,ascii; 


= Timing also includes time for procedure 
-— invocation. 
-> 3 nay 1983 


package body USER PROCESS 2 is 
procedure MAIN is 
maces tenweleneta.srcn are ,timer loop:integer; 
pegin 


-~- jnitialization 


arrayl := (°M , 


array2 := (’d’,°a’,’y°,otners => ° °); 
Srcen_lenetn := 22; 
Sronvarg s= 3; 
timer_loop <= 102609; 
put 2@(° Start of Search...2 )3 
put (BEL); 
put(BSL); 
.}: 
put (BEL); 
put( BEL); 
fOr,i in i.. timer_loop loop 
SEARCH(srcn_lengtn,srcn_arg,arrayl,arrav2,loc); 
end loops 7 
put 29( end tne searcn.....2 );3 
put(BEL); 
put( BEL); 
put( BEL); 
put (BEL); 
put(BEL); 
end MAIN; 
end USER PROCESS 2; 


161 





pragma environment( ACS: TEXTIO.MLE', INTIO.MSE , SCHAR.MSE™ 


“PR&MAIN.MSE )3 
Mmenoeue ttl O,!nbio,schar, wse text io,intio,schar,éscii; 


—= Timing also includes time for procedure 
= invocation. 
== 5 May 1983 


package body USER PROCESS 3 is 
procedure MAIN is 
h,20c,crch Jenegtn,srch_areg,timer loop : integer; 


begin 


Seeunitialization 


arrayl o= (age on dg a 8 we 5 8 ores mares eee 
crs eae Seite fis en eG tre iOQm cg. 6... 
others => 
array2 := (°d’,’a’,’y’,others => ” ”)3 
Srcen_leneth = 22; 
srcn_ arg 2= 33 
timer_loop := 180008; 
putees( Start of Search...3 ); 
put(BEL)}3 
put(BEL ); 
put( BEL); 
Buus ly ) > 
put(BEL); 


mOeeerern i.e. timer _loop loop 
SEARCH(srcn_lenetn,srcen_arg,arrayl,array2,loc); 
end loops 
put 2@( end the search.....3 )} 
put (BEL 
put( ESL 
put (EEL 
put (BEL 
put (BEL 
end MAIN; 
end USER _PROCESS_ 33 


Ree ee et et ee” 
We WO ~«wq SO WO 
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PR4MAIN.MBS 


—--CHARS1 driver routine 


pragma environment(” ACS:TEXTIO.MLE', INTIO.MSE , SCHAR.MSE™ 
“PR4MAIN.MSE ); 
wee "Vert 10,1ntio,schar; us@ text_io,intio,scnar,ascii; 


a PiiineecalSOsinciuaes tine for procedure 
= imvoca tion. 
aoa 5 May 1983 


package body USER PROCESS 4 is 

procedure MAIN is 
ioc, srcum enewa,Ssrcn darg,timer loop : integer; 
forever : boolean :=true; 
anSwer : character; 


begin 


wnile forever loop 


“-~ initialization 


arrayl := ila 
- 


otners > : or 


array2 := (’a  Vonotnens = 
srceh_lenetn : 
srcen arg : 
timer loon : 
put_20(°" St 
putt BEL}; 
put( BEL); 
put (BEL); 
tie eR 
put (BEL ); 
fOrsi inl... timer _ loop loop 
SEARCH(srcn_lengtn,srcn_arg,arrayl,array2,loc); 
end loop; 
put_20( end the sSearch.....4 )3 
put (BEL); 
put(BEL ); 
put (BEL); 
Dita ) > 
put(BEL); 
forever := talse; 
end loops 
end MAINS; 
end USER PROCESS 4; 
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DFPSERP1.MBS 
Pragma ete os ACS Beetle. ACSsVLUSRP.MLI- 
“PRIMAIN.MSE PROMAIN.MSE , PR3MAIN.MSE "PRAMAIN, MS) 
with Process Definitions, iMAX Definitions, 
Basic Process management; 
with User Process 1,User Process 2,User Process 3, 
User Process 4; 
package body User Processes is 


eerie GtO Ts 

= iiicmenodvlemernstantiates tne user processes and 
== provides an initialize procedure which completes the 
as initialization ot each user process. 


SS For each user process, tnere is an instance of 


=o IMAX Derinitions.procedure val which contains the 
-—- process” initial procedure. To minimize tne size2 of 
== this package, tne initial procedure nere simply calls 
aeons Micmac tua lnartidimemorocedure= which 1s “found™= in 
a another module. For each process, tnere is also an 


== Micdiarathoneot Process Definitions.Process Instance 
-—— which specifies the process id, the procedure_val 
-- just mentioned, and tne process” stack SRO and object 
= table sizes. 


SS Finally, tne initialize procedure provided by tnis 


aad module Simply calls roe 
-— Complete process initialization procedure 

= in eacn instantiation of 
== Process Definitions.Process Instance. 


procedure primain;, 
procedure predmain;s 
procedure prdémain; 
procedure pr4main; 


—— SPECIFICATIONS FOR USER PROCESS 1 -- 


package UPROC1 is new Process Derinitions.Process Instance 
(Process Startup => primain, 
SRO size => 4800); 
—~—mo2onvice periloed => 
bestcuprocess management. infinite_period count); 
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SSeoemeiu near tONS FOR USSR PROCESS 2 -- 


package UPROCe is new Process Defrinitions.Process Instance 
(Process Startup => pr2main, 
SRO size => 4200); 

“-- service period => 


basic_process management.infinite_period_ count); 


package UPROCS is new Process Detinitions.Process Instance 
(Process Startup => prdmain, 
SRO size => 49808); 
-- sefrvice_period => 
basic_process_management.infinite_period count}; 


—— SPECIFICATIONS FOR USER PROCESS 4 -- 


package UPROC4 is new Process Definitions.Process Instance 
(Process Startup => prémain, 
SRO_size => 4008); 
—- service period => 
Basic Process Management.Infinite Period count); 


procedure primain is 
begin 

Use menoce soli. MAINS 
end primains;s 


S—woCUIBomnork UobBR PRCCESS 2 == 


procedure premain is 
begin 

User Process 2.main; 
end pr2main; 
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procedure prdmain is 
pegin 

User Process 5.main; 
end prdamain; 


procedure prémain is 
begin 

User Process 4.main;s 
end prémain; 


procedure Initialize 

is 

begin 

GEnOCletomplete process initialization, 

-——- UPROC2.Complete process initialization; 
~- UPROCS.Complete process initialization; 
-- UPROC4.Complete process initialization; 

end Initialize; 
end User Processes; 
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DFPSERP2.MBS 
Pragma environment(— AGS. BPM .MLE | en CS: V1USRP. ini 
"PRIMAIN.MSE , PR2MAIN.MSE , PR3MAIN.MSE’ PREMAIN MSE” Ne 
With Process Definitions, iMAX_Definitions, 
Basic Process_management; 
with User Process 1,User Process 2,User Process &, 
User Process 43 
package body User Processes is 


=e t LON: 

== PeicmemoOOwte eins tantiales the user ovorocesses end 
io provides an initialize procedure whicn completes the 
ie initialization of @achn user process. 


== For each user process, tnere is an instance of 
=F IMAX Definitions. procedure val Wier acon vai ns. tne 
-- process” initial procedure. To minimize tne size of 
= this package, the initial procedure here simply calls 
a Ciemeaecuudl = Initial procedure which is found in 
= anotner module. For each process, there is also an 
a mecmcmuldltouwo, 6rocess Yetinitions.Process Instance 
== MiemnclemmeonecltteS tie Process id, the procedure val 
-—- just nentioned, and tne process” stack SRO ana object 
ca table sizes. 


=— Pedy ween e  ititialize procedure providec by this 
== module San Diy. Cais the 
== Complete _ process initialization Eno ced ine pins .ea cn 
= iMmecucamvratvom Of Processmvetinitions. Process Instance 


procedure primain; 
procedpre premdin ; 
procedure prdémain; 
procedure prémain; 


SoeOorocGINiCArONS FOR USER PROCESS 1 -- 


package UPROC1 is new Process Definitions.Process Instance 
(Process Startup => primain, 
SRO size => 4900); 
-- service period => 


Dotcom pnocess smandgement.torfinite period count); 
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=~ SPmGlrICGARIONS #OR USER PROCESS 2 -- 


package UPROC2 is new Process Detfinitions.Process [lastance 
(Process Startup => pr2main, 
SRO_size => 4900); 
“- service period => 
basic process management.infinite_period count); 


j—- oPemCITRICATIONS FOR USER PROCESS 3 -- 


package UPROCS is new Process Definitions. Process Instance 
(Process Startup => prdmain, 
SRO_size => 4200); 
se tyice period => 
basic_process_management.infinite_period count); 


—— SPECIFICATIONS FOR USER PROCESS 4 -- 


package UPROC4 is new Process Definitions.Process Instance 
(Process Startup => pr4main, 
SRO_size => 4802); 
—- s@rvice period => 
Basic Process Management.Infinite_ Period count); 


procedure primain is 
vegin 

UiSctmeemocess 1.MAIN; 
end primain; 


— ae oDiomnoneUohR PROCESS 2 -- 


procedure premain is 
begin 

User _Process_2.main; 
end préemains 
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procedure prdémain is 
begin 

User Process 3.main; 
end prdmain;s 


procedure prémain is 
begin 

User Process 4.main; 
end pré4main; 


-- PROCEDURE TO INITIALIZE ALL YSER PROCESSES -- 
procedure Initialize 
is 
devin 
Teer econprete process initialization; 
OPROC2 .Compiete process initialization; 
-- UPROCS.Complete process initialization; 
-=seurmoeces. complete process initialization; 
end Initialize; 


end User Processes; 
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DFPSERPS .MES 


Pragma environment("ACS:BPM.MLE , ACS:V1USRP.MLI, 
“PRIMAIN.MSE , PR2MAIN.MSE , PR3MAIN.MSE , PR&MAIN.MSE”); 
with Process Definitions, iMAX Definitions, 
Rasic_Process managerent; 
with User Process 1,User Process 2,User_Process_5, 
User Process 4; 
package body User _Processes is 


aa Ue L1 On: 

= This module inStantiates tne user processes and 
I Dreeovedeseaneaumytidlize procedure which completes tne 
a initialization of eacn user process. 


-— ier sedchumm user precess, tnere 16 an instence of 


aa iMAX Definitions.procedure val worchwecOntains — the 
-- process’ initial procedure. To ninimize the size of 
ao this package, the initial procedure here Simply calls 


== Picmeccuucdclen Inttidadl  precedure which is found in 
a anotner module. For each process, tnere is also an 
m= instantiation of Process Definitions. Process Instance 
-— which specifies the process id, the procedure val 


-- just mentioned, and the process” Stack SRO and object 
—— pebeemes 12 6S. 


oe Finally, the initialize procedure provided dy tnis 
== module Simply calls Lae 
== Comprete process initialization procedure in eacn 
== instantiation of Process Detinzitions.Process Instance 


procedure primain; 
procedure premain; 
procedure prdmain; 
procedure pr4émnain; 


package UPROC1 is new Process Definitions.Process Instance 
(Process Startup => primain, 
SRO_size => 4009); 
—- service_period => 
pasic_ process _management.infinite_period_count); 
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-- SPECIFICATIONS FOR USER PROCESS 2 -- 


package UPROC2 is new Process Definitions.Process Instance 
(Process Startup => premain, 
SRO size => 4020); 
-- service period => 
basic_process _management.infinite_period_count); 


“~~ SPECIFICATIONS FOR USER PROCESS 3 -- 


package UPROCS is new Process Definitions.Process Instance 
(Process Startup => prdmain, 
SRO size => 4200); 
—~- service period => 
basic process management.intinite period count); 


-- SPECIFICATIONS FOR USER PROCESS 4 -- 


package UPROC4 is neéw Process Definitions.Process Instance 
(Process Startup => prémaia, 
SRO_size => 488@); 
-- service period => 
Basic Process Management.infinite Period_count); 


Dpreceaure primdin 15 
begin 

User _Process_1.MAIN; 
end primain; 


==—spoULPomeen USER PROCESS 2 <= 


procedure premain is 
begin 

QUser Process 2.main;s 
end pr2main; 





procedure prdémain is 


vegin 
User Process _3.main; 


end prdmain; 


=— BODIES FOR USER PROCESS 4 -- 


procedure prémain is 
begin 

User Process 4.main; 
end pré4main; 


—~- PROCEDURE TO INITIALIZE ALL USER PROCESSES -- 


procedure Initialize 
is 


dvegin 
UEteree COMPLE TS process initielization; 
UPROC2.Complete process _ initialization; 
UPROCS.Complete_process_initialization; 
m= UPROC4 .Complete process initialization; 
end Initialize; 


ena US@Tr Froce’sses; 
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DEPoeaPs.4BS 


Praema ee ganet a PACS SE PMEMirn uA GeV IOUSRP. an at 
“PRIMAIN.MSE PROMAIN.MSE’ » PR3MAIN.MSE’ "PRAMAIN MSE 3 
witn Process Definitions, MAA Deriniticis, 


Basic _ Process management ; 
with User Process 1,User_ Process 2,User _Process ce 


User Process 4; 
package body User Processes is 


emetic ho 0s 

=— Vicmiotimee mm imMstantidhbes | the pser processes and 
i provides an initialize procedure whicn comoletes' the 
ho initialization of e@acn user process. 


= DOrmepecatcommuser process, tnere is an instance or 
== PAxevetiaiy?ons.procedure val wane emcOm ra. 1S sab oe 
eda process’ initial procedure. To minimize the size of 


== ose Daokdce .t2e Inte dt Drocedure HRere simply calls 
—— bwewreectuUar Initial procedure Which is founc inh 
aa another module. MORecaCR DEO Cesc. tmere 1S cisco <an 
roe instantiation of Process Definitions.Process Instance 
= which specifies tne process id, the procedure val 


—- just mentioned, and tne process” stack SRO and otject 
= table sizes. 


—— Finally, the initialize procedure provided dy itinis 
== module Samp iy Garais tne 
== Geommenete process initialization DEoceuuren in eac 
aoe Mioetubiaoton of Frocess Pefinitions.Process Instance 


procedure primain; 
procedure premain; 
procedure prodmain; 
procedure pr4émain; 


DaemecomllemwGr 1S new Process Derinitions.Process Instance 


(Process Startup => primain, 
S908 _size => 4920); 
-- service period => 


basic_process management.infinite perioa_count); 


Tho 





——ormemr von 1ONs FOR USER PROCESS 2 -~-- 


mae kae@e YRROC2l i5 new Process Definitions.Process Instance 


(Process Startup => premain, 
SRO_size => 4066); 


“-- service period => 
basic_process_management.infinite period count); 


a SooeolhI@RTIONS FOR USER PROCESS 3 -- 


paemace UMROCS 15 new Process Definitions.Process Instence 
(Process Startup => prdmain, 
SRO_size => 4208); 
“- service period => 
basic_process management.infinite perioc_ count}; 
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—-- SPECIFICATIONS FOR USER PROCESS 4 -- 


package JUPROC4 is new Process Definitions.Process Instance 


(Process Startup => prémain, 
SRO_size => 4080); 
—-- service period => 


Basic_Process Management.Infinite Period _ count); 


procedure primain is 
bervin 

User Process_1.MAIN; 
end primains 


procedure voréemain is 
begin 
USereprocess 2.mainy 


end pr2main; 


procedure prdémain is 
begin 

Yser Process 3S.mains 
end prdmain;s 


procedure prémain is 
begin 

User Process 4.main; 
end prémain; 
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proceamre initialize 

is 

begin 
OPROC1.Complete process initialization; 
UPROC2.Complete _process_initialization; 
UPROCS.Complete process initialization; 
UPROC4.Complete process initialization; 

end Initialize; 


end User Processes; 
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DieauNk? LX D 


meorms~tnuct2on test program 


link ACS:minmazx.eod 
BGS steztio.mlo 
Mitlo.mso 
schar.mso 
schar.mbdo 
primain.mso 
préemain.mso 
prdmain.mso 
pré4main.mso 
primain.mbo 
préeémain.mbo 
prdomain.mbo 
prémain.mbdo 
dfpserpl.mbo 
psors .mbo 


free(3@ in directory) 


output dicharl.eod 


objectmap 


melnmstruction test program 


link ACS:minmax.eod 
ACS :textio.mlo 
intio.mso 
schar.mso 
schar.mbdo 
primain.mso 
préemain.mso 
pr3main.mso 
prémain.mso 
primain.mbo 
préeémain.mbdo 
prémain.mbo 
prémain.mbdo 
dfpserp2e.mbo 
psors .mbo 


free(3@ in directory) 
OuUmsut Guenarc.eod 


OO eCtmayp 


LL 





DFLINKS.LKD 


wees trict. on Lest program 


link ACSsminmax.esod 
Ae Ge XtLO.mLo 
intio.mso 
schar.mso 
scnar.mbo 
primain.mso 
préemain.mso 
pr3main.mso 
pré4main.mso 
primain.mbo 
premain.mbo 
promain.mbo 
prémain.mto 
afpserpds.mbdo 
psors .mbo 


free(3@ in directory) 


Supmput drpenars.ecod 


objectman 


DFLINE4.LKD 


[eens tcuet1on test program 


link ACS:minmax.cod 
Ate mr tO 6 M1 O 
intio.mso 
scnar.mso 
scner.modo 
primain.mso 
prerain.mso 
prdmain.mso 
pré4main.mso 
primain.mbdo 
premain.mbdo 
prdmain.mbdo 
pré4main.mbdo 
ifpserp4.mbdo 
psors.mbo 


free(3¢@ in directory) 
output ifcnar4.eod 


objectmap 


ie 





ENFPSERPI.MES 
Praegma environment(— ACS: BPM. MLE ACS : VLUSRP. MT 
"PRIMAIN.MSE', PR2MAIN.MSE” ,"PRSMAIN.MSE’ ‘PRAMAIN. MSE" 
with Process Definitions, iMAX Definitions, 
Basic Process management; 
with User Process 1,User Process 2,User Process 3, 
User Process 4; 
pecmace body User Processes is 


rnc t LON 

== This module instantiates the user processes and 
—— PecwlaeS are intticdiilze @procedyure which completes tne 
=~ initialization of each user process. 


== HOR eteCummISer | precess, there is dan instance of 
aa Lime tinet. ONS. procedure val which contairs cae 
-- process” initial procedure. To minimize tne size of 
ies this package, tne initial procedure nere simply cells 
== Mem actuals inivial “procedure which 1s found ir 
a anotner nodule. For each process, tnere is also an 
=a iim h ra teon Of Process Definitions.Process Instance 
-— Reece cit les TNE process id, the procedure val 
-- just mentioned, and the process” stack SRO ana object 
a Coreme SIZES. 


== Finally, the initialize procedure pvrovided by this 
eS mod te Simply Capes Ene 
== Ceomprete process initialization procedure in eacn 
ee mistanGiation of Process  verinitions.Process Instance 


procedure prinain;s 
procedure premain; 
procedure prdnain; 
procedure prémain; 


oo eee LONG FOR USER PROCESS 1 -- 


package UPROC1 is new Process Definitions. Process Instance 
(Process Startup => primain, 
SRO size => 4098, 
service _ period => 
basic_process management.intinite_period count); 


Digg GS, 





een ht ONG FOR USER PROCESS 2 -- 


package UPROC2 is new Process Definitions.Process [Instance 
(Process Startup => premain, 
SRO_size => 42800, 
Service_period => 
basic process _nanagement.infinite_period_count); 


package UPROC3 is new Process Detinitions.Process Instance 
(Process Startup => prdmain, 
SRO_size => 42302, 
Senvices oe T1odg)—> 
basic_process management.infinite periocac_count)s; 


=o esolficelLONS FOR USER PROCESS 4 -- 


pacmaezemurnOC’ 16 new Process Definitions.Process Instance 
(Process Startup => prémain, 
SRO size => 4006, 
service period => 
Basic_Process_Management.Infinite_ Period count); 


procedure primain is 
begin 

User Process 1.MAIN; 
end primain; 


-- BODIES FOR USER PROCESS 2 -- 


procedure prémain is 
begin 

Se Termocess 2.main; 
eng pPremad ne 


1<0 





meee soe nOR UStR PROCESS 5 == 


procedure prsmain is 
begin 

User Process 5.main; 
end prdmain; 


procedure prémain is 
berin 

User Process 4.mains 
end pré4main; 


procedure Initialize 

1s 

begin 

UPROC1 .Complete process initialization; 

Pru riroGescCo plete process_initializations 
SOKO coomNplLete process initialization; 
== UPROCS Complete process initialization; 

Siaeinitialize, 


end User Processes; 


2a 





INFPSERPC.MBS 
Pragma environmeny( ACS:BPM.MLE”, ACS:V1USRP.MLI”, ; 
PRIMAIN.MSE , PREMAIN.MSE , PROMAIN.MSE , PR4&MAIN.MSSE ); 
wernerrocess Vefinitions, iMAA_Definitions, 
Basic Process management; 
oememuse= sPtoGess.1,User Process 2,User Process 3, 
WS ie Jeecie aes 
package body User Processes is 


-- Function: 


== This module instantiates the user processes and 
—< provides an initialize procedure which completes the 


ia initialization of each uSer process. 


== HOGmmcCacummmUSer S process, there 1S an instdnce of 
alam iw ecru ft Ons.procedure val which contains pimae 
-- process’ initial procedure. To minimize the size of 
ee this package, the initial procedure nere simply calls 


== iemecaablale 121tTidl precedure which 1s found in 
“= anotner module. HOT seaeumonrocess, there 1s aiso an 
=o Wiaimiaar VON OterrOCcessmpelinitions.Process Instance 
== Meco pe Ch LES = the process id, the procedure val 


-—- just mentioned, and the process” stack SRO ana otject 
-- table sizes. 


= Finally, the initialize procedure provided by this 
== module Simply calls the 
= Gompeeteeprocess initialization procedure in Pace 
oa moan giatnon Of Process Vetinitions. Process Instance 


procedure primain; 


procedure preémains;s 
procedure pr3nain; 
procedure pr4émain; 


package UPROC] is new Process Definitions.Process [Instance 
(Process Startup => primain, 
SRO size => 4¢¢¢, 
service period => 
basic_process_management.infinite_perioda_count); 


Zc 





Paeimare UEHUGe 15 new Process Definitions.Process Instance 
(Process Startup => pr2main, 
SRO size => 4808, 
service_period => 
basic_process management.intinite_period count); 


pacKaze UPROCS is new Process Definitions.Process_Instence 
(Process Startup => prdmain, 
SRO_size => 4920, 
service period => 
basic_process_ management.infinite_period_count); 


package UPROC4 is new Process DTefinitions.Process Instance 
(Process Startup => prémain, 
SRO_size => 4002, 
service _perioi => 
Basic_Process Management.Infinite Period count); 


DEoceaune Ollimaln 15 
bezin 

Userernocess 1.4AIN; 
end primain; 


procedure —premain 15 
bezin 

User Process 2.main; 
end premain; 


L23 





“~~ BODIES FOR USER PROCESS 3 -- 


procedure prdmain is 
begin 

User Process _3.main; 
end prdmain, 


—-- BODIES FOR USER PROCESS 4 -= 


procedure pr4é4main is 
vegzin 

User_Process_ 4.main; 
end pr4main; 


procedure Initialize 
is 
vegin 
Peovuenoonple Te process initialization; 
UPROCe.Complete process_initialization; 
-~- UPROCS.Complete process_initialization; 
~~ UPROC4.Complete process initialization; 
eid Got atl 76; 


end User Frocesses; 





INFPSERPS.MES 
Pragma environment(— ACS*BPM MLE , "ACS: TUCRE aM bi 
PRIMAIN.MSE PR2EMAIN.MSE , "PR3MAIN.MSE. R "PRaMAIN. NS UR 
with Process Definitions, iMAX Definitions, 


Basic Process management; 
with User Process 1,User Process 2,User Process 3, 


User Process 43 
package vody User Processes is 


=—— Functions: 


cl This module instantiates the user processes and 
-=- provides an initialize procedure which completes the 
= initialization of eacn user process. 


a BOC eo Cim~—ISeT Sphocess, there is dan instance of 


an iMAX Definitions.procedure val wnich contains tae 
-- process” initial procedure. To minimize tne size of 
= We comoeemice tne niyias orocedure nere simply calls 
=— Tiemmaculete  ANnitial procedure which is found in 


-- Aanotner nodule. Horeca Gnieamnocess, tue re 1S also an 
= Miata rom Crm. TOCeSs verinitions.Precess Instance 


-— eae pecit les = tne process id, the procedure val 
-- just mentioned, and the process” stack SRO and onject 
aa table sizes. 


== Finally, the initialize pvrocedure provided Dy this 
== module Simply eas tne 
=F Tome Lemumocess initialization procedure ir eaca 
=< Bice tone or =r nocess DeTinitions. Process Instance 


procedure primain; 
procedure premain; 
procecvre pronain ; 
procedure prémain; 


Nea gett ome tis new Process Detinitions.Process Instance 


(Process Startup => primain, 
SRO_size => 4¢0¢, 
service_period => 


basic_process management.infinite period count); 





—— SPECIFICATIONS FOR USER PROCESS 2 -- 


package UPROC2 is new Process Definitions.Process Instance 
(Process Startup => pr2main, 
SRO_size => 4200, 
service _period => 
basic_process management.intinite_ period count); 


“—- SPECIFICATIONS FOR USER PROCESS 3 -- 


package UPROCS is new Process Definitions.Process Instance 
(Process Startup => prédmain, 
SRO size => 422, 
service period => 
basic_processS management.infinite_period_count); 


Baermaee UPRUOG iS new Process Definitions.Process Insetance 
(Process Startup => prémain, 
SRO size => 4¢@¢, 
service period => 
Basic Process Management.Infinite Period _count)s 


proceanure prindin is 
begin 

Uaemmemocess 1.4AlN; 
end primain; 


See OUR omeOnovotn PROCESS 2 =-- 


procedure pr2dmain is 
begin 

USereyrocess ¢.main; 
end premain; 


L2e 





procedure prémain is 


degin 
User Process 3.main; 
end prdmain; 


procedure prémain is 
begin 

User Process _ 4.main; 
end prémain; 


procedure [Initialize 

ics 

Degin 
Cee oonple tom process 1 nitidlization; 
UPROC2.Complete process initialization; 
UPROCS.Conplete process initialization; 

Uric COompLele process initialization; 
end Initialize; 


end Jser_ Processes; 


Pi 





INFPSERP4.MBS 
Pragma environment( ACS:BPM.MLE , ACS:V1USRP.MLI', 
‘PRIMAIN.MSE , PR2MAIN.MSE’ ” PR3MAIN, MSE,” PR4MAIN MS Y;3 
with Process Definitions, iMAX Definitions, 


Basic Process manavement; 
with User Process 1,User Process 2,User_ Process =o; 


User Process 4; 
package body User Processes is 


Seri nC tL On s 

i This module instantiates tne user processes and 
ia provides an initialize procedure which completes tne 
== Pcs ct Manon eco nmeilscer Drocess. 


=< For ®ach user process, there is an instance of 
= Mit mvcomeneecrOnS.procedure yal which Contains pe 


-- process” initial procedure. To minimize the size of 
== Wobecmpacesee s,s tne initia] procedure nere Simply calls 
== MCCcmmecColictm initial snrocecure which is found in 
taal another nodule. For @ach process, there iS al50 an 
a iisedivrdt’onee: Frrocess Definitions.Process Instance 
-- Piveomeomoec thes S tNe process id, the procedure val 


—— just mentioned, and the process” stack SRO and object 
aoe Pero re Sizes. 


== myoaliye the initialize procedure provided oy tnis 
== module Samp ly Gall s ais 
= Complete process_initialization procedure in eaen 
Sa ict aitiat yon Ot Process Definitions. Process [Instance 


DpEOcesures prigiailn; 
procedure premain; 
woo Ceawremor cna 5 
procedure sprémain; 


bechaeeomucrmeGamis New Process Definitions.Process Instance 


(Process Startup => primain, 
SRO size => 40@¢, 
service period => 
basic process management.infinite period count); 





package UPROC2 is new Process Definitions.Process Instance 
(Process Startup => pr2main, 
SRO size => 4040, 
Service period => 
basic process management.infinite_ period count); 


oe UCL tem ONe FOR USER PROCESS 3 <-- 


= 4G CG se EE a Gp 6 6 Se GE EE Se ana GR oS > = Gap 2 2 Ge ae Ca Gp 6 > am o> ab Ep = =p ap 


package UPROCS is new Process Detinitions.Process Instance 
(Process Startup => prdmain, 


SRO size => 4000, 
Service_period => 
Vee mcm proces smemancarement.iJatinite period count ) +s 


Ee 2 aE GRE EE EF Dar GE 2" Ga GP GED Ge “O@= GO 6 0 S86 OS GP GE GD GD GEG BD GP Gp Gm €°? > aa a 


pie eteemuenoot is new Process Definitions.Process Instance 
(Process Startup => pr4émain, 
SRO size => 49@¢@, 
Service _period => 
Basic Process Management.Infinite_ Period count); 


procedure primain is 
dbezin 

Ucebermocess 1. MAIN; 
end primain; 


procedure premain is 
pezin 

Userearaocess 2.main; 
end préemain; 


LEAS, 





procedure prdmain is 
begzin 

User Process _3.main; 
end prdmain; 


procedure prémain is 
begin 

User Process _4.main; 
end pré4main; 


procedu.e Initialize 

is 

beein 
Ueueet.COmpLete process initialization; 


YPROC2.Complete process initialization; 

UPROCS.Complete process initialization; 

reece. complete process initialization; 
end Initialize; 


enlae User Frocessess 
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INLINK1.LKD 


; instruction test program 


link ACS :minmax.eod 
hoo. textio.mlo 
intio.mso 
schar.mso 
scnar.mbo 
primain.mso 
prémain.mso 
prémain.mso 
prémain.mso 
primrain.mbo 
prémain.mbo 
proémain.mbo 
prémain.mbo 
infpserpl .mbo 
psors.mbdo 


free(3@ in directory) 
Om@put infcaarl.cod 


objectmap 


» instruction test program 


link ACSsminmax.eod 
MCs: Lek GlO.m10 
intio.mso 
schar.mso 
schar.mbdo 
primain.mso 
préemain.mso 
promain.mso 
pr4main.mso 
primain.mbdo 
prémain.mbo 
prdmain.mbo 
pré4émain.mbo 
infpserp2.mbo 
psors .mbo 


free(3O in directory) 
OUT out 2neenarc.eod 


objectmap 


ey 





INFLINKS.LED 


jensStruction test program 


link ACS:minmax.eod 
ACS :textio.mlo 
intio.mso 
scnar.mso 
schar.mbo 
primain.mso 
premain.mso 
prémain.mso 
prémain.mso 
primain.mbo 
premain.mbo 
prdmain.mbo 
pré4main.mbo 
infpserpds.mbo 
psors.mbdo 


free(3@ in directory) 
output infchars.eod 


Oba =c tmap 


INFLINKS .LKD 


seas Gruction test prezgram 


link ACS:minmazx.eod 
ACS :textio.mlo 
intio.mso 
scnar.mso 
schar.mbo 
prirain.mso 
premain.mso 
prsémain.mso 
pré4émain.mso 
primain.mdo 
pré2emain.mbo 
pr3main.mbo 
pré4main.mbo 
infpserp4.mbo 
psors.mbo 


tre2(3@ in directory) 
Ole OU eum cnars.eod 


objectmap 


Gye 





Sadaé4s2new 


Sida 
Sida 
ee 

ida 
Sida 
Sida 
Sida 


AGioretnt)0.mss 

scnar.mss 

schar.mbs 

[rogers.common] primain.mss 
frogers.comnon] pr2main.mss 
{rogers.common] pr3main.mss 
[rogers.common] pr4main.mss 


> purge 


Sida 
Sida 
Sida 
Sida 


primain.mbds 
premain.mbds 
prdmain.mbs 
pré4main.mbs 


Spurge 


Sada 
Sida 
Sida 
Sida 


[rogers.connonJdafpserpl.mds 
frogers.common|dfpserp2.mbs 
[rogers.common]dfpserpd.mbs 
frogers.common] dfpserp4.mbs 


Spurge 


Sida 
Sida 
Sida 
Sida 
Sida 


{rogers.common]infpserpl.mbs 
[rogers.commnonjJinfpserp2.mbs 
ee eee SN ZpeerpS .mbs 
rogers.comnonjinfpserp4.mbs 
[rogers.common] psors.mbs 


spurge 

S$link432 [rogers.common]¢cflinkl 
Slink432 [rogers.common|dflink2 
Slink432 EER Lad Debra 


Slink452 


rogers.commonjdflink4 


Slink432 [rozers.common]Jinflinkxl 
Slink432 frogers.commonJinfiink2 
Slink432 frogers.common}inflink3 
Slink4$2 [rogers.commonjintlink4 
Source 

Saelete “src; * 
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